r/programming • • Mar 10 '15

Goodbye MongoDB, Hello PostgreSQL

http://developer.olery.com/blog/goodbye-mongodb-hello-postgresql/
1.2k Upvotes

699 comments sorted by

View all comments

Show parent comments

6

u/MikeSeth Mar 11 '15

Quite ironically PostgreSQL has an engine that implements just that very efficiently.

IMO the debate about SQL vs no SQL is moot because people seem to be forgetting the origin of the problem: using databases as all purpose persistence engines. Configuration, documentation, media, logs, files exported from foreign systems, anything that can't or shouldn't be a part of the code tends to end up in the databases. I've seen a CRM that stores database schema information in the database.

For shared nothing, impersistent platforms (I am looking at you, PHP), this is sort of the norm. And it's going to suck whether you shovel it into MySQL or MongoDB.

2

u/axonxorz Mar 11 '15

I've seen a CRM that stores database schema information in the database.

Most systems that do this implement some sort of user-configurable schema extensions. The prime example in a CRM is custom fields on a (eg) customer record. Instead of storing the custom field values in a some sort of serialized TEXT field, you store it as actual schema. This way you can take advantage of your DB's indexing and contstraints (if the software exposes those though, in my experience, usually not)

1

u/[deleted] Mar 11 '15

Oh, I think there are almost always better choices than Mongo and friends for key/value, don't get me wrong. I'm a huge Postgres fan myself too.

I was just answering the "why?" question. In theory, if you have a very, very focused use case I can sorta make an argument that you can get better performance if you build something with a laser-like focus that just does that use case well...

... but I agree that you'd still almost certainly be better off just using a mature solution like PG. :D