11–20 of 160 posts
I'm nearly sure one day someone will write a MongoDB compatibility layer on top of PostgreSQL
Not exactly what you were looking for, but you can connect from PostgreSQL to MongoDB via Foreign Data Wrappers - https://github.com/citusdata/mongo_fdw
Earlier quoted context omitted.
That's sensible when you consider that postgresql used to be a SQL layer over postgres. Not sure if that is the case now.
> That's sensible when you consider that postgresql used to be a SQL layer over postgres. Were they ever actually separate layers? I thought that PostgreSQL was a rename of Postgres that happened shortly (one-two versions) after they swapped query languages from the Ingres-derived QUEL to SQL.
I'm nearly sure one day someone will write a MongoDB compatibility layer on top of PostgreSQL
Earlier quoted context omitted.
Not exactly what you were looking for, but you can connect from PostgreSQL to MongoDB via Foreign Data Wrappers - https://github.com/citusdata/mongo_fdw
I know about Foreign Data Wrappers and use them extensively. To clarify, what I want is to have a quick engine swap for some legacy apps without touching anything but config files.
Earlier quoted context omitted.
> That's sensible when you consider that postgresql used to be a SQL layer over postgres. Were they ever actually separate layers? I thought that PostgreSQL was a rename of Postgres that happened shortly (one-two versions) after they swapped query languages from the Ingres-derived QUEL to SQL.
Postgres95 had both if I remember. Sorry was nearly 20 years ago now - bit rusty :)
I'm nearly sure one day someone will write a MongoDB compatibility layer on top of PostgreSQL
PostgreSQL has native json support now. What else is missing? Just a protocol implementation? I'd love to see MongoDB give up and become a PostgreSQL consultancy. Everybody I talk to in the field has the exact same Mongo story: "We love JSON! We use JSON everywhere! We just wanted a DB with native JSON support. We didn't look at the implementation details. We only looked at their marketing. Now we wake up at 3am to f…
Yes. Actually that's why I said that I'm nearly sure.
As a side note: We may also need some rumors on being "web scale" (Actually I don't even know much about the events/comments/whatever which lead to that famous video but I still find it funny)
Earlier quoted context omitted.
I know about Foreign Data Wrappers and use them extensively. To clarify, what I want is to have a quick engine swap for some legacy apps without touching anything but config files.
Haha, did you just refer to Mongo in the context of legacy apps? I feel old and tired, and we're not even 10 years into this....
I'm nearly sure one day someone will write a MongoDB compatibility layer on top of PostgreSQL
PostgreSQL has native json support now. What else is missing? Just a protocol implementation? I'd love to see MongoDB give up and become a PostgreSQL consultancy. Everybody I talk to in the field has the exact same Mongo story: "We love JSON! We use JSON everywhere! We just wanted a DB with native JSON support. We didn't look at the implementation details. We only looked at their marketing. Now we wake up at 3am to f…
Client A: Read JSON.
Client B: Read JSON.
Client A: Append new comment to json document.
Client B: Append new comment to json document.
Client A: Save JSON
Client B: Save JSON
I am in no way advocating for MongoDB (I dislike it). I am just saying that I understand that MongoDB has much more sophisticated updates capability than Postgres.
* didn't read the manual
* poor schema
* didn't maintain the database (compactions, etc.)
In this case, they hit several:
" Its volume on disk is growing 3-4 times faster than the real volume of data it store;"
They should be doing compactions and are not. Using PostgreSQL does not avoid administration; it simply changes the administration to be done.
"it eats up all the memory without the possibility to limit this"
That's the idea -- that memory isn't actually used though; it's just memory mapping the file. It will swap out for something else that needs the space unless you are actively using all the data, in which case you really are using all your memory. Which is why you should put it on its own server...
"it begins to slow down the application because of frequent disk access"
"Finally we sleep quietly, and don’t fear that mongodb will drive out redis to swap once again."
You should be running Mongo on a server by itself. At the very least, if you're having disk contention issues, don't run it on the same server as your other database.
I'm not sure you always need to read the manual for everything, but for your production database, it's probably worth it.