On: How to Efficiently Choose the Right Database for Your Applications

[deepsun]

I kinda disagree with separate branch for "document database" for Mongo. Mongo is a key-value storage, with a thin wrapper that converts BSON<->JSON, and indices on subfields.

You can achieve exactly the same thing with PostgreSQL tables with two columns (key JSONB PRIMARY KEY, value JSONB), including indices on subfields. With way more other functionality and support options.

[gqewogpdqa → deepsun]

Not really true. MongoDB natively supports sharding, multiple indexes, high availability, arrays, sub documents, array traversal, etc - all able to be accessed in your native language with get/set functionality (or via MQL if you want). While PostgreSQL is a really powerful database, the JSON support is really painful to program against.

[tankenmate → gqewogpdqa]

Postgres supports sharding (and partitioning) also with some limitations by expression and multi level as well. HA obviously exists for Postgres in a number of forms, obviously there are limits, but then CAP is an issue for all forms of distribution regardless of DB type. Postgres supports arrays, JSON arrays, JSONB arrays, also indexes on arrays, traversal and looping on arrays, etc. And you get almost all of this via SQL (which you can then map onto your dev language choice via various libraries, personally I don't use ORMs if I can help it, I used SQL in my models as it eases performance tuning. I do realise that a lot of devs don't do or understand SQL, but then I find that a case of the dev not knowing their craft well enough; you need to understand not just logic but data as well). Also more recent version of postgres (12+) have proper support for JSON path queries.

Using Postgres with JSON operators isn't that difficult, of course there are some pitfalls and corner cases due to Postgres's architectural choices but then you'll get that with just about any DB choice. And if Postgres's JSON operators aren't to your taste there are JSONPath queries you can use too.

[tehlike → deepsun]

This. Postgres as a document db is more capable than mongodb.

[westurner → deepsun]

> You can achieve exactly the same thing with PostgreSQL tables with two columns (key JSONB PRIMARY KEY, value JSONB), including indices on subfields. With way more other functionality and support options.

PostgreSQL docs > "JSON Functions and Operators" https://www.postgresql.org/docs/current/functions-json.html

MongoDB can do jsonSchema:

> Document Validator¶ You can use $jsonSchema in a document validator to enforce the specified schema on insert and update operations:

   db.createCollection( <collection>, { validator: { $jsonSchema: <schema> } } )
   db.runCommand( { collMod: <collection>, validator:{ $jsonSchema: <schema> } } )

https://docs.mongodb.com/manual/reference/operator/query/jso...

Looks like there are at least 2 ways to handle JSONschema with Postgres: https://stackoverflow.com/questions/22228525/json-schema-val... ; neither of which are written in e.g. Rust or Go.

Is there a good way to handle JSON-LD (JSON Linked Data) with Postgres yet?

There are probably 10 comparisons of triple stores with rule inference slash reasoning on data ingress and/or egress.

[tgv → deepsun]

If mongodb is a key-value storage, then so is postgresql, but you make it sound as if it's something to stay away from.