Hacker News Reader

Comment by coleifer | Hacker News Reader

I authored a python binding and have some experience that may be relevant.

The library seems poorly maintained in my opinion and might be abandoned. There have been critical bugs leading to data loss. They have a similar project vedis which is like an embedded redis that I think is completely abandoned.

For the love of God just use SQLite if you want an embedded database for structured data, even if it's just eav. If you just need key/value there are battle-tested, well maintained options.

https://github.com/symisc/unqlite/issues/41

View on HN

> For the love of God just use SQLite if you want an embedded database for structured data, even if it's just eav. If you just need key/value there are battle-tested, well maintained options.

You can also use the SQLite Disk Btree as a key-value data store. I've just implemented a solution that does so in C++ with a LevelDB-like api.

You should use the backend Btree api (the same the VDBE/SQL engine uses to store stuff) and create 'tables' the SQLite uses for indexes. The integer-key based is used for ordinary SQL table .. (1 PK = 1 Record) and the blob-key type, where its agnostic about whats on the key. (Thats the one you use to create the KV store)

There are a couple of details, to make it right, but its not that hard, and its a great solution.

The Btree engine in SQLite is quite inefficient, and also unreliable on its own. (Needs the transaction log support to provide reliability.) LMDB blows it away.

https://github.com/LMDB/sqlightning

Agree here with the comment nothing compares to the solid codebase of SQLite. This project in my opinion trys to win your trust with QLite in name and does not deliver same quality.

You've posted the same two-year-old closed issue twice on this thread. You're coming off as someone with an axe to grind.

People often get passionate about data corruption.

I just want to share my experience, which is extensive.

Reply on news.ycombinator.com