I am sure there is some way to work around this, but wouldn't this be the default behavior with a typical database and typical COW file system?
Is this the correct talk: https://youtu.be/dwMQXLOXUco?t=5380 ?
What you are describing can be done with PostgreSQL. One thing that is missing is better client libraries that make use of those data types. Morphia wins for now in that regard.
Postgres storing JSON types != All mongo functionality
I'm sure I could achieve everything I'm doing in mongo by some roundabout way in Postgres, but if you're doing a large amount of reading/modifying partial fields within JSON structure, it's the exact use case for mongo.
that said, I actually use partial JSONB updates on a regular basis, but I tend to use PLV8 to do the heavy lifting.
(1) It's a proof of concept, (2) it hasn't been updated in 3 years and (3) it still isn't the same syntax as MongoDB.
The point still remains that PostgreSQL isn't just a 1-1 replacement for MongoDB which is pretty common sense to me anyway.
1) it's a proof of concept that others have improved upon to show that you can indeed replace the functionality of mongo that most developers tend to rely on.
2) neither has mongodb at that level
3) that's correct, you need to actually use the term SELECT when you use the functions
and you are correct, pg is missing the random data loss that comes with mongo. it will never be 1-1 in regards to that.
EDITING TO ADD:
the important part is the note (the bulk of the comment) that I'm updating partial JSONB data on a very regular basis, and do it using PLV8, getting rid of the need for an unreliable database and instead using exactly what this news story is about.
It is a MongoDB-compatible server that supports speaks the MongoDB Wire Protocol (and therefore can be used with the same drivers used to connect to any standard MongoDB server) but stores your data into a reliable and trusted ACID database."