Both PBKDF2 and scrypt are key derivation functions (KDFs) that implement key stretching by being deliberately slow to compute and, in particular, by having an adjustable parameter to control the slowness.

The difference is that scrypt is also designed to require a large (and adjustable) amount of memory to compute efficiently. The purpose of this is to make cracking it harder to parallelize using devices like GPGPUs or custom ASIC / FPGA hardware. Such devices may have hundreds or even thousands of parallel processing units, each capable of hashing a different password using traditional KDFs like PBKDF2, which don't require much memory. However, it turns out that, at least using current technology, providing each of these parallel units with large amounts of memory space is a lot more difficult and expensive than making the units themselves.

Another difference between PBKDF2 and scrypt is that PBKDF2 is a generic construction for turning any cryptographic hash function (actually, a pseudorandom function, but the most common way to obtain a PRF for PBKDF2 is to build one out of a hash function using the HMAC construction) into a key-stretching KDF. Thus, the actual KDF you use might be e.g. PDFKD2-HMAC-SHA256, meaning PBKDF2 built on HMAC built on the SHA-256 hash function.

Scrypt, on the other hand, is a specific key derivation function with "no user-replaceable parts inside". While scrypt does make use of some standard functions and constructions (in fact, it internally uses PBKDF2-HMAC-SHA256 for the state expansion and compression stages), the scrypt specification doesn't make any allowances for, say, changing the hash function to something other than SHA-256. It's a "take it or leave it" deal.

That said, it would, in principle, be possible to define a new KDF using the priciples described in the scrypt paper, but with different components. In particular, the scrypt paper defines scrypt as an instance of a more general construction called MFcrypt, instantiated with HMAC-SHA256 and the memory-hard mixing function SMix (also defined in the paper). It would be possible to use an MFcrypt instance with, say, SHA-3 instead of SHA-256, but that function would no longer be "scrypt" as defined in the paper.

Both PBKDF2 and scrypt are key derivation functions (KDFs) that implement key stretching by being deliberately slow to compute and, in particular, by having an adjustable parameter to control the slowness.

The difference is that scrypt is also designed to require a large (and adjustable) amount of memory to compute efficiently. The purpose of this is to make cracking it harder to parallelize using devices like GPGPUs or custom ASIC / FPGA hardware. Such devices may have hundreds or even thousands of parallel processing units, each capable of hashing a different password using traditional KDFs like PBKDF2, which don't require much memory. However, it turns out that, at least using current technology, providing each of these parallel units with large amounts of memory space is a lot more difficult and expensive than making the units themselves.

Another difference between PBKDF2 and scrypt is that PBKDF2 is a generic construction for turning any cryptographic hash function (actually, a pseudorandom function, but the most common way to obtain a PRF for PBKDF2 is to build one out of a hash function using the HMAC construction) into a key-stretching KDF. Thus, the actual KDF you use might be e.g. PBFKD2-HMAC-SHA256, meaning PBKDF2 built on HMAC built on the SHA-256 hash function.

Scrypt, on the other hand, is a specific key derivation function with "no user-replaceable parts inside". While scrypt does make use of some standard functions and constructions (in fact, it internally uses PBKDF2-HMAC-SHA256 for the state expansion and compression stages), the scrypt specification doesn't make any allowances for, say, changing the hash function to something other than SHA-256. It's a "take it or leave it" deal.

That said, it would, in principle, be possible to define a new KDF using the priciples described in the scrypt paper, but with different components. In particular, the scrypt paper defines scrypt as an instance of a more general construction called MFcrypt, instantiated with HMAC-SHA256 and the memory-hard mixing function SMix (also defined in the paper). It would be possible to use an MFcrypt instance with, say, SHA-3 instead of SHA-256, but that function would no longer be "scrypt" as defined in the paper.