Database row level encryption scheme
The way the iterations work is that it roughly increases your security (in bits) by $\log_2(iterations)$.  So you would still need $\frac{\log{2}}{\log{97}}\cdot (256 - \log_2(10000)) \approx 37$ characters in your password to have 256-bits of security.  Think of it this way, if you have $2^{256}$ possible keys, that is an astronomically large number.  Much more than the number of elementary particles in the universe.  In comparison, 10,000 is basically nothing.  Increasing the keyspace gives you exponential security, while adding iterations to your key derivation function gives you only linear security.  It's nice, but at the end of the day it doesn't help as much as you think it does.

Having said that,  you probably don't need 256-bits of security anyway.  As I said before, that is a ridiculous amount of security.  No increase in computational power will ever let anyone brute force a 256-bit key.  There are physical limits to computation, and it would take something like the entire energy of a dozen stars to be able to do that.  The reason we have things like AES-256 is that we anticipate in the future people will find more efficient attacks against AES which do not require brute forcing.  But, with a longer key we hopefully delay these attacks.  So, if someone discovers an attack which works in time $2^{n/2}$, AES-128 will be effectively broken.  But, with AES-256 we still have 128-bits of security, which should suffice for a while longer.  

For 100 years, the number of bits of security you really need is closer to 120-150.  The outside limit of what anyone can brute force today is probably 70-80 bits, and remember adding bits gives you exponentially more security.  So, you would really only need a password that was 17-20 characters long.