You are sharing IV: cells from a given row will use the same IV. This is bad. Don't do that.
You use CBC; this is a mode which is known to have a few security issues (in particular, it is sensitive to "how much random" the IV is), and it will involve padding (since CBC encrypts only full blocks, you have to extend the data elements to the next size which is a multiple of the block size).
If you modify one of the encrypted cells, then you must reencrypt it. If you use the same key and same IV, then you have lost (security wise). Therefore, you must alter the IV for that cell. If you use the same IV for the whole row (which is bad), then you must reencrypt the other cells of the row as well.
A MAC is needed if potential attackers could modify the data in place; it is not if attackers are assumed to be passive only. Note that an attacker could modify the encrypted data in order to observe how your system reacts, and try to deduce things about the encrypted data. As a general rule, you are better off with a MAC than without.
I would therefore suggest altering your scheme into the following:
- Use an authenticated encryption mode with associated data which combines encryption and integrity, like EAX or GCM.
- User a per-cell IV, stored in the cell itself. EAX and GCM do not need a random IV, only an IV which is never repeated (for a given key), so you could use a simple counter: maintain a system-wide global counter, incremented every time you need to encrypt a new cell value (when you allocate a cell, and also when you replace the contents of the cell); store the counter in the cell itself (that way, a 64-bit counter will be enough, no need to go to a full 128-bit value).
- AEAD modes include an integrity check which is computed over the data which is encrypted and some additional data which you can choose (the "additional data" is used for computation but is not stored in the encrypted result; you must provide it again upon decryption, so that the integrated MAC can be checked). Encode in that "additional data" the row and column numbers for the cell. That way, an evil active attacker will not be able to silently swap cell contents (the MAC will be OK only if the cell contents are still where they should be).
Also, don't indulge in the "rotating master key" fantasy. The only reason why you would have to change the master key is in case it was stolen; and, in that case, you must change it right away for the whole database. No need for a smooth, gradual transition: this is an emergency situation. Therefore, no need to keep a version number for the master key. An identifier for the cryptographic algorithm, on the other hand, is a good idea; it can fit on a single byte (or even less than that).
Encrypt the binary data, not a Base64 encoding of it. Encryption output will be binary anyway. Applying Base64 on the input will just make the data 33% larger, for no good reason.