if you open the Sqlite source, the Vdbe engine, the engine that process the SQL queries to the backend, use a "simple" key value store, that is the on-disk btree backend of the sqlite.. so you can create a btree api-like using other key-value store as backend, and it would work the same..
This way you can give a full SQL engine to any key-value store out there..
Thats why the Sqlite4 are being designed to be more plugable.. with a shim key-value wrapper over the storage backend that can be changed, in compile time, or even in runtime given its use of C callbacks.. (but dont know any reason someone would want to to that.. to do a runtime switch anyway)
Replacing the btree engine in SQLite3 is far from easy. BerkeleyDB did it with major surgery to the SQLite3 source tree. LMDB did the same. https://gitorious.org/mdb/sqlightning
This way you can give a full SQL engine to any key-value store out there..
Thats why the Sqlite4 are being designed to be more plugable.. with a shim key-value wrapper over the storage backend that can be changed, in compile time, or even in runtime given its use of C callbacks.. (but dont know any reason someone would want to to that.. to do a runtime switch anyway)