I think this approach manages to combine all the disadvantages and almost none of the benefits of SQL and NoSQL (and threads?). It's cute but seriously, where would this ever be practical? Consider the alternatives:
If you need concurrent client transactions over sets wouldn't you be better off just using a SQL database?
If you need fast KV, why not just use NoSQL over SQL ala memcache or something newer like memcache/innodb[1] ?
If you want complex updates over redis why not just use redis 's Lua interface[2]?
I think sqlite4's approach[3] (SQL above NoSQL) makes a lot more sense than this since it will presumably let me write a SQL application and deploy it with any KV store.
If you need concurrent client transactions over sets wouldn't you be better off just using a SQL database?
If you need fast KV, why not just use NoSQL over SQL ala memcache or something newer like memcache/innodb[1] ?
If you want complex updates over redis why not just use redis 's Lua interface[2]?
I think sqlite4's approach[3] (SQL above NoSQL) makes a lot more sense than this since it will presumably let me write a SQL application and deploy it with any KV store.
1- https://blogs.oracle.com/MySQL/entry/nosql_to_mysql_with_mem...
2- http://oldblog.antirez.com/post/redis-and-scripting.html
3- http://www.sqlite.org/src4/doc/trunk/www/design.wiki