You say that each row is encrypted with a different password, and you want to make it slow for an attacker to perform a blanket decryption of the entire table even if they know all of the passwords.
Since encryption happens with keys, not passwords, there's another piece you haven't mentioned: The means by which passwords become keys. If you're worried about passwords (not keys) being stolen, this is a fine place to manufacture your slowness. If you define the key as 4096 re-hashings of the password, it will be 18 years of Moore's Law before that process is as fast as a single hashing today. If 18 years isn't long enough (it's not!) then keep doubling.
Iterative hashing has its pitfalls however. The chance of collisions is increased, unless you mix some salt with each iteration. See: Strength of multiple hash iterations?
I also wonder if you're not being myopic in tackling this particular problem. "Passwords" (as typically defined) do not contain enough entropy to produce cryptographic key material in the first place. You need a "passphrase" instead, or you're losing the game.