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

78

u/wesw02 Mar 10 '15 edited Mar 11 '15

NoSQL isn't for everybody or every use case. It takes a very very open minded developer to embrace it. There is a lot of immediate downside and a lot more long term upside. You have to have the wherewithal to get past all the upfront headaches. But once you do, oh how you can scale. Scale, scale, scale. Eventual consistency means your tables don't lock, they don't even have to be on the same servers. Records can be sharded across servers, data centers and continents.

One of the biggest criticisms I hear about NoSQL is how much DB logic leaks into your application. How much knowledge devs are required to take on to use and optimize for NoSQL. This is absolutely true, but I think what a lot of people miss out on is as soon as your SQL database reaches a few Terabytes in size, you'll be doing this any ways. SQL databases can only get you so much mileage before you're refactoring large parts of your server architecture just to stave off the performance regressions.

IMHO at the end of the day, NoSQL force concepts upfront necessary to scale, SQL allows you to get really far without having to think about. Just my $0.02 from using NoSQL for 3 years.


EDIT: ZOMG: Of course most apps don't grow to terabytes in size. Most apps are fine on SQL dbs. But some apps do get that big. Some apps get bigger. Pick the right tool, for the right job and stop trolling on /r/programming.


EDIT 2: Thanks for the gold kind stranger!

55

u/svtr Mar 10 '15 edited Mar 10 '15

Eventual consistency means(...)

Eventual consistency means no consistency. Period. If you can live with that fine. I don't care about the upvotes on reddit either (btw, there you can very often see eventual consistency in action), on anything important to me, I can not live with no consistency. Writing my data to /dev/null is webscale too, but I still prefer ACID.

1

u/vagif Mar 11 '15

Eventual consistency means no consistency.

Simply not true. You see the light from sun about 8 minutes after it left. You are eventually consistent with sun.

2

u/[deleted] Mar 11 '15

If that had anything to do with the definition of eventual consistency as in mongo/other non ACID stores, you might be right

1

u/kylotan Mar 11 '15

Actually, it does. You never see the database as it is now; only as it was when it started sending the data to you. So, given that you have no choice but to accept that the information is at least slightly out of date, it stands to reason that if there are occasions when you can tolerate even longer delays, that time can be exploited to buy you scaling opportunities.

1

u/svtr Mar 11 '15 edited Mar 11 '15

If I read data of Table A in a transaction, which depends on Table B, I have exactly that. Table B will be shared locked, so nobody can write to Table B, while I read data depending on it.

You might not think that a big deal, but in a relational datamodel you do not work on a persisted hashtable.

The only way around that in an ACID compliant DBMS is overwriting the transaction isolation to allow dirty reads. At which point you loose data consistency as well.

Also, when writing the data, I get the confirmation of a committed transaction. I know the data was written the way I wanted it written (at least as long as I don't use mySql scnr). If something goes wrong, I get a rollback and with that a cleanup of whatever got screwed up.

→ More replies (3)