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

Interresting... wondering if I can easily map the kv part to say lua's table dictionary

As per the AGPL, you don't actually have to distribute stuff that is linked to an AGPLed library or other software, if you are only using it internally (and/or via a network). Because you can claim it as GPL3, which doesn't have the network distribution clause...

From clause 13 of the AGPL: Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.

[1] http://www.gnu.org/licenses/agpl.html

[2] https://en.wikipedia.org/wiki/Affero_General_Public_License#...