Consider SQLite 3, I am using a project that stores large amounts of data on the client and is doing well.
I hope the criteria for db selection focus primarily on functional coverage and orthogonality and portability (platform and skill) and ignore linear speed factors. I have had really good luck with SQLite3 as well.I understand the instinct, but SQLite is an RDBMS, and as such it is ill-suited to this. Functionality will be provided through RPC calls, not by sacrificing speed because we implemented an entire RDBMS (albeit one that is self-contained). The blockchain needs to be in a fast key-value store so that commonly hit functions (network catch-up, scanning when restoring a wallet or re-syncing one, key image scanning for double-spend prevention) are blazingly fast both now and in future. Given the size of the key image table / index, it would take tens of seconds for you to send a transaction if we used SQLite.
Of course, the fact is that we are abstracting the DB functionality, so someone else can have an active fork that uses SQLite.
Test the performance before deciding discart. My company is developing a CAT:
http://en.wikipedia.org/wiki/Computer-assisted_translation
Our searches in database are extremely heavy.
. I always close the daemon after save with exit...and when I started it actually moved several hundred blocks ahead before entering orphan loop This time I won't delete downloaded blockchain 
