I think it's use-case is when your data is more structured than what Berkeley DB can handle but doesn't really fit neatly into tables. Not using SQL as a query language is a plus in some scenarios too, particularly if your data manipulation needs are a bit more complex and you don't have the room for importing and using a full ORM (which is a "Vietnam of Computer Science"[1] anyway).

[1] http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute...

You don't need a full blown ORM here. A rather thin access layer would suffice, as much I can see from the API.

What I can see here, is that the data store is just a big JSON-file. So the implementation does not scale well (every save just writes the whole database and the database must be read in total to access any tiny bit of data). For any even medium sized application, it would be better to use a more sophisticated basis.

Maybe as configuration database -- but even for that, I guess there are already better choices in existence.

Edit: Upvoted the OPs post, because of the Vietnam-Link -- good read. Still, I would not throw RDBMSes totally out of the window. I think, we have learned a lot from them and in many, many cases they are just right. There are some cases of course, where object oriented schemes are more appropriate.

> You don't need a full blown ORM here.

Precisely my point, you don't need an ORM with this LanderDB, but you'd need it with SQLite (unless you like using raw SQL, which is a fine preference too, of course).

> What I can see here, is that the data store is just a big JSON-file.

One possible use-case for this I recently discovered is storing bookmarks in Chrome (https://klibert.pl/output/jq_and_chrome_bookmarks.html).

I'm not saying LanderDB is the best option and as smt88 wrote there certainly are many alternatives. I'm just noting that LanderDB doesn't seem to occupy the same niche as SQLite.

EDIT: oh, and I'm in no way involved with LanderDB, I just saw it a couple minutes ago :)

It sounds like you're describing an embeddable document store. There are options for that as well:

- UnQLite: http://charlesleifer.com/blog/python-bindings-for-unqlite-an...

- tinydb: https://pypi.python.org/pypi/tinydb/

- Blitz: https://github.com/adewes/blitzdb

I didn't know about these, thanks.

Sqlite now supports JSON.

You still have to use SQL to query it though, right? JSON is just a data type option, to my knowledge.

When is it better to use something else?

Oh I personally have no problem with SQL. Another commenter was just saying you might want to use LanderDB when you don't want to use SQL.

It was mainly created for P2P systems that need to sync databases across clients. Being that data is stored in JSON it can be sent and received with relative ease.

...duh... instead a sqlite file is so difficult to share?

Why use sqlite when you can invent something new which has no concurrency semantics and eats up inodes?

sqlite is thread safe?

Yeah, I remember reading about it a couple of months (years?) ago and being very surprised and impressed. The details: https://sqlite.org/threadsafe.html

SQLite databases are just as "easy" to send and receive. In fact, they can be compressed, which means they're even easier.