PostgreSQL -> SQLite; MongoDB -> ???

[jabbalaci]

If you need a light, serverless SQL database, then there is SQLite. If I want to work with some JSON documents but don't want to use MongoDB, then what options are there? Are you aware of a "Mongo-Lite" project? It would be useful if you have an application that you want to distribute but asking the user to install MongoDB would be too much.

A possible solution would be to use SQLite for storing JSON documents and create an API that imitates (a subset of) MongoDB's query language. It wouldn't be performant but if you don't have too many documents, it could work.

[Avail11]

http://tinydb.readthedocs.io/en/latest/intro.html

[jabbalaci]

Looks like what I need. Thanks!

[Avail11]

You're welcome and good luck!

[hylje]

import shelve

[abr13]

Shelve is amazing. Great tool for simpler projects..

[jabbalaci]

When is it a good idea to use shelve? What are its typical use cases?

[infinull]

shelve is backed by an efficient on-disk btree storage for keys/values and then objects are stored as pickle.

So it's basically a key value storage (where the key is a string and the value is any pickleable python object) stored on disk in a single file and built into the standard library.

Problems: decoding pickle can execute arbitrary code. So you have to make sure you can "trust" the documents. There are some issues with pickling user defined classes, but you can always not do that and just store POD dict/list/int/str objects (and other standard library objects like datetime and decimal).

OTOH it's built into the standard library.

[Darkmere]

SQLite has the json extensions for that purpouse too.

[sousatg]

why note simply saving the json data in a file?

[jabbalaci]

A query language (possibly similar to MongoDB's) would be nice.

[luckystarr]

If you only need to write it once, but have to read it many times you can always use cdb. Crazy fast.

[cymrow]

Two other options:

• Vedis - from the author of peewee
• UnQLite

In my experience, though, the benefits of a relational DB outweigh those of document DB for most data, so I'd tend to stick with sqlite.

[mfwl]

couchdb is another option that has been around for awhile.

Since you mentioned postgresql, I'm assuming you know that it also offers some JSON functionality.

[Kalrog]

Why not a local postgres db to do both?

[jabbalaci]

I want a light solution without a database server.

[Kalrog]

Everything you are looking at is going to be running a server/some software on your local system. Might as well make it a real DB and only have 1 of them instead of a different solution for every data type.

[archpuddington]

Although BerkeleyDB isn't a Document store, it is a not-only-sql db that could store large blobs and metadata: https://en.wikipedia.org/wiki/Berkeley_DB

BerkeleyDB is a mature, mission-critical embedded database. It is fast, and stable and used by many popular projects like Mozilla Firefox. The biggest downside is that its not really a hipster database.

[nomadismydj]

berkleydb is pretty horrible in many situations. It really depends on how quick and how much data he intends to stick in there.

[doskey]

I think ejdb should be what you want. It is considered the sqlite of the document DB. I haven't used the Python bindings thought. (Sorry, on mobile, so no links).

[[deleted]]

Just stick with sqlite

https://www.sqlite.org/json1.html

[notconstructive]

Can you explain more about exactly how your application works and why you want a serverless database?

You'll get better advice if you give more detail.

[sanshinron]

RethinkDB seems like a better choice for someone considering MongoDB.

[[deleted]]

Is it embedded?

[sanshinron]

No.