4 ms·

This is a side feature for Postgresql and other relational dbs. MongoDB focuses on especially this. I would not mix the two concepts. Split of the relational d

This is a side feature for Postgresql and other relational dbs. MongoDB focuses on especially this. I would not mix the two concepts. Split of the relational data and make it fast with relational DBs. Everything else goes in MongoDB and if fields always occure, they move into the relational DB.

Ididntdothis 7y ago
I would mix the two. JSON columns allow you to deal with unstructured data in Postgres so you don't have to manage two databases. I much prefer that.
- alexbanks 7y ago
  I agree with you on the original premise of "Why would you use Mongo over Postgres?", managing two DBs is terrible. But if you replace Mongo with something like DynamoDB, I think it gets more complicated. You don't really "manage" DynamoDB as much as just define what you're trying to do, as it's a managed service. I quite enjoyed using DynamoDB for some specific tasks at work, much more than I've enjoyed PostgreSQL's JSON columns.
  - mixermachine 7y ago
    I would use the best tools even if it requires two DBs. When I have many transcations with many joins but also user documents (maybe from a online editor which is currently still in heave development), I would use two DBs.
- Beefin 7y ago
  In an ideal world yes, you only manage one database but no such "jack of all trades" DB exists for the same reason the CAP theorem remains true. If your Postgres JSON schema modified for new application requirements, the table is locked until existing data is copied into the new schema, requiring applications to be quiesced during schema migration. Thats a key difference between the two and one area Mongo performs best in.
  - Ididntdothis 7y ago
    Sure there are situations where a Postgres/Mongo hybrid is the best but my preferred default is Postgres only. In most cases this will work fine, is simple and straightforward. Why make things more complicated than necessary?
  - nicoburns 7y ago
    > If your Postgres JSON schema modified for new application requirements, the table is locked until existing data is copied into the new schema, requiring applications to be quiesced during schema migration. Are you saying that if you INSERT a row with a new JSONB property that wasn't previously included in any of the rows of that table, then the entire table gets locked while all rows are copied. And if so, do you have a source for that? I can't find anything through google.
sinkasapa 7y ago
I've been using jsonb columns in PostgreSQL recently and have used CouchDB extensively in the past. I find the builtin support for JSON superior in PostgreSQL. There are a lot of nice built in operators for querying and creating indexes is much more concise. I wouldn't call it a side feature at all.

Ididntdothis 7y ago

I would mix the two. JSON columns allow you to deal with unstructured data in Postgres so you don't have to manage two databases. I much prefer that.

alexbanks 7y ago
I agree with you on the original premise of "Why would you use Mongo over Postgres?", managing two DBs is terrible. But if you replace Mongo with something like DynamoDB, I think it gets more complicated. You don't really "manage" DynamoDB as much as just define what you're trying to do, as it's a managed service. I quite enjoyed using DynamoDB for some specific tasks at work, much more than I've enjoyed PostgreSQL's JSON columns.
- mixermachine 7y ago
  I would use the best tools even if it requires two DBs. When I have many transcations with many joins but also user documents (maybe from a online editor which is currently still in heave development), I would use two DBs.
Beefin 7y ago
In an ideal world yes, you only manage one database but no such "jack of all trades" DB exists for the same reason the CAP theorem remains true. If your Postgres JSON schema modified for new application requirements, the table is locked until existing data is copied into the new schema, requiring applications to be quiesced during schema migration. Thats a key difference between the two and one area Mongo performs best in.
- Ididntdothis 7y ago
  Sure there are situations where a Postgres/Mongo hybrid is the best but my preferred default is Postgres only. In most cases this will work fine, is simple and straightforward. Why make things more complicated than necessary?
- nicoburns 7y ago
  > If your Postgres JSON schema modified for new application requirements, the table is locked until existing data is copied into the new schema, requiring applications to be quiesced during schema migration. Are you saying that if you INSERT a row with a new JSONB property that wasn't previously included in any of the rows of that table, then the entire table gets locked while all rows are copied. And if so, do you have a source for that? I can't find anything through google.

sinkasapa 7y ago

I've been using jsonb columns in PostgreSQL recently and have used CouchDB extensively in the past. I find the builtin support for JSON superior in PostgreSQL. There are a lot of nice built in operators for querying and creating indexes is much more concise. I wouldn't call it a side feature at all.