Hey all. I worked on the UnQLite development team back into 2013 ~ 2014. It was designed to be the primary storage for a home targeting router manufactured by a French tech conglomerate.<p>The API is broken down into two independent layers plus one for various utility stuff like cross platform mmaped files, RC4 random numbers generation and so on. The first layer serve as a general purpose key/value store for the host application blobs (i.e binary or text data). You can store whole disk files inside a single database to generate a cross platform TAR archive for example.<p>The second one is the document store layer similar in concept to what MongoDB offer but without the networking layer since everything run in the same process of the host application. Both layers are transactional and are able to recover after some external failure thanks to the SQLite journaling mechanism from which UnQLite is based on.<p>Since its release in 2013, there was four major bugs including two critical that involves data loss under certain load. All known data corruption bugs were fixed in the last release and no major bugs were discovered a year or so.<p>The library enjoy particular success among Python and C/C++ developers especially Chinese that used to bombard the original developers with various internal aspect of the library.
I authored a python binding and have some experience that may be relevant.<p>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.<p>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.<p><a href="https://github.com/symisc/unqlite/issues/41" rel="nofollow">https://github.com/symisc/unqlite/issues/41</a>
The licensing is not altogether obvious. There seems to be a "one time fee" for downloading.
The name sort of implies a connection with SQLite. No such connection exists.
There is a parent company, name of "Symisc Systems". Which appears to be just one guy somewhere in France or Tunisia who likes to call himself "we".
The code is not too kindly treated by several who have actually tried to use it.<p>I think I'll pass.
> <i>UnQLite is a standard key/value store similar to BerkeleyDB, LevelDB, etc. but, with a rich feature set including support for transactions (ACID), concurrent reader, etc.</i><p>This is slightly interesting, since the big reason I personally prefer applications using SQLite over those using BerkeleyDB (which used to be <i>very</i> common, btw) is that I’ve had <i>lots</i> of problems in the past with corrupted BerkeleyDB files. Like, almost all the time; if it used BerkeleyDB, it would sooner or later get corrupted. If UnQLite can be a “non-corrupting BerkeleyDB” for those who don’t actually need SQLite, it can serve an (admittedly niche) purpose.
> This production-ready package is available for a one-time fee of $20.<p>Don't fault them for trying to make a bit of cash but going to have to pass since I'm too poor to spend $20 to see if it's a viable replacement for a little project I built on top of tinydb that's getting pretty slow since the db has grown past what a pure python db can comfortably handle.<p>Or...I suppose they could provide a link from their download page to their github repo for us somewhat lazy folks -> <a href="https://github.com/symisc/unqlite" rel="nofollow">https://github.com/symisc/unqlite</a>
Is there any documentation of the testing/verification process used in UnQLite? One of the things that gives me confidence in SQLite is <a href="https://www.sqlite.org/testing.html" rel="nofollow">https://www.sqlite.org/testing.html</a> and it'd be interesting to see what approach UnQLite takes to the same problem.
From the FAQ:<p>"7. Is UnQLite thread-safe<p>Threads are evil.[1] Avoid them.<p>UnQLite is threadsafe and full re-entrant. But in order to be thread-safe, UnQLite must be compiled with the UNQLITE_ENABLE_THREADS compile time directive defined. If you are unsure if the UnQLite library you are linking against is compiled to be threadsafe you can call the unqlite_lib_is_threadsafe() interface to find out."<p>[1] <a href="http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf" rel="nofollow">http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1....</a> "The Problem with Threads"<p>"Threads are evil" is not a useful remark to make in response to the question "is this library thread-safe"
this is great - in my opinion there's a shortage of key value type data storage engines and there needs to be more competition in this regard. There simply aren't enough free/open source data engines to meet the demand of today's software.<p>few quick thoughts - how does this compare to leveldb? How would it perform in something like geth or parity as an ethereum client back end data engine in compared to leveldb? do you have a python interface library?
The name though — what is it supposed to mean? “Un” as in “One” in French with QL Lite or “Un” as in a prefix for an opposite in English with QL Lite (like “No QL Lite”)?
This is a good example of someone twisting the term "serverless" to capture attention:<p>> <i>Serverless Database Engine</i><p>> <i>Most NoSQL database engines (i.e. MongoDB, Redis, CouchDB) are implemented as a separate server process. Programs that want to access the database communicate with the server using some kind of interprocess communication (typically TCP/IP) to send requests to the server and to receive back results. UnQLite like SQLite does not work this way. With UnQLite, the process that wants to access the database reads and writes directly from the database files on disk. There is no intermediary server process.</i><p>The fact that it's embedded doesn't actually have anything to do with what popular "serverless" architectures are designed to solve, i.e. writing code that does not need to run in a specific server process to be invoked on demand. By their definition of serverless, pretty much any library is "serverless"...<p><i>Edit: This is referring to "Classic Serverless" (<a href="https://sqlite.org/serverless.html" rel="nofollow">https://sqlite.org/serverless.html</a>) not "Neo-Serverless" architecture (my definition is more like "Neo-Serverless"). Thanks parhamn for pointing out the distinction.</i>