Poll: Would you be interested in a 'NoSQLlite' database?

2 points by webmaven ↗ HN
SQLlite is a very useful component, both as a local test DB for web development and as part of many desktop apps.

Given that NoSQL databases can be useful for reasons other than horizontal scaling, it occurred to me to see if there were any lightweight NoSQL datastores that could be used in the same contexts as SQLlite, and found a few (Whitedb, LiteDB, UnQlite, etc.), but none seem particularly popular.

So, do you use one or would you find one useful?

And if so, which flavor of NoSQL?

3 comments

[ 1.6 ms ] story [ 13.5 ms ] thread
"NoSQL" + "local store" combines to pretty much just be "the data structure I want" + "a serialization library", especially for testing purposes. You've got things like BerkeleyDB that go back decades. I suspect this is why you don't see a lot of uptake on this idea.

Something that was 100% API compatible with a common store but ran locally for testing might be useful, but that 100% compatibility requirement is a heck of an ask for anything much more complicated than memcached. Even that would still be a project.

To my way of thinking, "NoSQL" + "local storage" still leaves a lot more in the way of features than just serializing a data structure to disk, or I would be satisfied (in Python) with pickle and shelve.

At a minimum I would want:

* Transactions

* Indexing

* A query language

And that is without considering various features that would be specific to particular data store types (or data types).

That said, you could be right that it isn't a problem most developers have, and for those that do, existing solutions fill the niche adequately.

"That said, you could be right that it isn't a problem most developers have,"

What I mean isn't that it isn't a problem, but more that it isn't a problem acute enough to make people go looking for solutions.

By sheer coincidence, I was actually writing some code today that implements an API that backs to many DBs, sorta a crappy NoSQL layer, backing to Postgres. And I had to write the test suite to work against Postgres. I already have the test suite running against SQLite, but there's enough differences that it's not a relevant test. I have to bring up the "real thing". I suspect that's just what most people do.