There are other more pedestrian concerns to consider that have not been mentioned. Most RDBMS's provide infrastructure services for handling backups, recoveries, rollbacks, auditing, etc.. These are arguably somewhat mature.

What I hear you asking for is idiomatic data persistence.

I tried reaching for this recently on a project in the Java world by using Derby. I'm not recommending either - don't misunderstand. The point I want to offer is that though I was able to use this tool with idioms native to the language, the challenges we faced had more to do with supporting a production application than with the efficiency of the programming model.

In the end we went with the more traditional approach, not because it was more convenient to code - it wasn't - but because it was easier to support from an operational standpoint.

I am not trying to discourage you however, merely shedding light on important functionality often considered an afterthought that perhaps should be included in the discussion.

Frankly I'd like to see something like this in a truly robust form. Personally, I find the endless vendor variations of SQL tedious.