My 2 cents:
I work as LOB (line of business) application developer in the private sector and I am pulling my experience from there.
There are 2 basic DB types that have been brought up here: relational and K,V (or NoSQL).
Given the vast difference between these two their abstraction layers are also very different, so just by choosing one you have already locked yourself into a technology.
I would design an API that is purpose built for armory, a custom abstraction layer if you will. That way if in the future you decide that you want to swap LevelDB our for membase, or mongo, or even a full blown Oracle instance you only need to change your underlying API calls.
Given what I have seen of your code so far I would bet you were planning on doing that already.
I hear 2112's pain as in our line of work you get many executives that read or hear buzzwords and then demand (for no good reason) that 'we are going nosql now!'
However I do not agree that K,V stores are necessarily a step backward, they do have their purpose and as you pointed out etotheipi they are damned fast. (See
http://readwrite.com/2010/08/18/membase-the-database-powering)
I think LevelDB is the correct choice at this time. I don't think that most Armory users would benefit form the full features of a RDBMS, while at the same time any kinks that come up with LevelDB will most likely be addressed by the core team first (or at least will have some insight).
As an aside:
However I personally wish that as a community we could use SQLite for the underlying wallet format. The reason is it would support a standard schema as well as purpose built client additions without breaking each other. Also you wouldn't be 'locked out' you can read/write SQLite files on any OS. However I don't think that is going to happen