Or just single PostgreSQL would do better, because Mongo's feature set is a subset of PostgreSQL's feature set.
Just a slight warning on this, because I was mildly burnt by hearing this and assuming it was true.
For background, I'm a long time happy Postgres user.
Recently I decided to use it for a new project instead of Mongo and to utilise the new JSON support.
Turns out it is great for CRD apps, not so much for CRUD.
The current release version of Postgresql (9.3) has no capability to do updates to parts of JSON stored as the JSON datatype (ie, you have to read the entire JSON blob, change it and write it back)[1].
Some updates are done in place, some are not. To give a specific example - integer updates are always done in place. The most common reason that a document has to be rewritten is when it is updated size is too big to fit into its previous space. Then it has to be moved.
Could be, but that article just says that the update is "in place." Which may mean that just the changed int is written, or it may be the entire document.
But, it's in the box API functionality... since it's a single record, there's minimal locking involved. Depending on your load that can be very important.
For that matter, imho doing a locked partial update via something like _.assign would be fine imho in postgres. It depends on how you really need to use your data... and how it fits into that.
If you have a lot of recursion in your data, it may be better suited towards sql... if you have a lot of data gathered around a group of objects/documents a document db like mongo/rethink/elasticsearch may be best... if you really need key/value lookups, then cassandra is hard to beat.
For that matter, having data duplicated/replicated to multiple types of db servers is entirely reasonable. You management UI can interact with an SQL datastore, and on save, you also save to Mongo.
That was the interim step I chose in migrating our data structures.. the queries that run against mongo work great, there's three servers in the replica set, for a relatively small data set, and it is really nice.
Right. It's a confusing space because even though couch/riak/mongo are all "document databases" their storage engines are very different. You can't usefully generalize from couch's append-only b-tree to mongodb's mmap'd data files.
You're right. I just meant a little different thing: that we'd better store JSON in conventional way of storing values in schema-full columns. For example, object {foo: {bar: [1, 2], a: 'b'}} would be three columns foo.bar.0=1, foo.bar.1=2, and foo.bar.a='b'. In medium-sized project you'll write DAO layer to convert DBMS view on data to application code view on data anyway for various purposes. It would be even better, because column order in SQL doesn't matter (but in Mongo it does for searching, as it's essentially just BSON string). And column names won't be repeated each time and take space.
Of course, if you have a case to store unstructured data where you don't know the structure in advance, in this case it won't work for you. But for your own data -- we'd better let DBMS maintain the schema, instead of maintaining it in application code (inventing the wheel).
Side note, regarding updates of particular fields in objects: a NoSQL datastore must provide some "compare-and-set" functionality to avoid race conditions during updates. PostgreSQL way is to use row-level-locking transactions, but MongoDB locks the whole collections (well, several months ago it blocked the whole database, so it's and improvement :). They kinda offer findAndUpdate() for "compare-and-set", but see my another comment below on why it doesn't work.
Great info, thanks! We are using MongoDB for single-server installations and it fits our needs pretty well. Our biggest gripe is that disk space is not freed when collections are dropped, but we can live with it. Other things are just minor inconveniences which plague other DBs too. In our experience MongoDB "just works" - but then again, we don't use its scaling capabilities.
That said, we are looking around to see if there is an even better document-oriented DB available and PostgreSQL looks interesting (with its JSON). Haven't had the chance to try it yet though. Another interesting option is OrientDB (having graph database would be beneficial - but only for small part of our system). Does anyone have experience with other document-oriented storages? (primarily single node usage)
OrientDB is the most interesting alternative to MongoDB with support for Multi-Master replication and relationships: you can decide to embed or link documents:
Just a slight warning on this, because I was mildly burnt by hearing this and assuming it was true.
For background, I'm a long time happy Postgres user.
Recently I decided to use it for a new project instead of Mongo and to utilise the new JSON support.
Turns out it is great for CRD apps, not so much for CRUD.
The current release version of Postgresql (9.3) has no capability to do updates to parts of JSON stored as the JSON datatype (ie, you have to read the entire JSON blob, change it and write it back)[1].
Updates within JSON fields are coming in 9.4.
[1] http://dba.stackexchange.com/questions/54663/how-can-i-updat...