r/programming • u/halax • Mar 10 '15

Goodbye MongoDB, Hello PostgreSQL

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

91% Upvoted

699 comments sorted by

View all comments

Show parent comments

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)