3 ms·

First of all https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem, and that's something that you of all people should know. (Or e

First of all https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem, and that's something that you of all people should know. (Or even https://en.wikipedia.org/wiki/Consistency_(database_systems)#As_a_CAP_trade-off https://en.wikipedia.org/wiki/Consistency_(database_systems)... in the article that you linked.) Please read the rest of my previous comment. Repeat after me: PostgreSQL isn't ACID in a distributed system. PostgreSQL isn't actually ACID when your database is multiple machines. PostgreSQL isn't actually ACID when you set up your first read replica on RDS. PostgreSQL isn't actually ACID when you use streaming or logical replication. PostgreSQL isn't actually ACID when you start sharding your users table. PostgreSQL isn't actually ACID in a world in which people need to scale out from one big box. It's eventually consistent, which is even less than I can say about MongoDB on a single-document level. Personally, PostgreSQL is my favorite DBMS. It's well-engineered, extremely mature, and has lots of great features. Working seamlessly and providing strong guarantees outside a single box, unfortunately, isn't one of them. Not yet, at least. To address the rest of your points: those people are using MongoDB wrong. PostgreSQL basically stops working well too, once you start mixing transaction processing and business reporting and BI in the same box at scale. If you're going to claim that MongoDB is bad because it's not ACID or somesuch, you better hold PostgreSQL to the same standard, and understand precisely why it is that the two systems were built so differently.

dustingetz 9y ago
ACID's C is about the write side: "ACID is a set of properties of database transactions" (wikipedia) which is different than CAP's C: https://en.wikipedia.org/wiki/Consistency_(database_systems)#As_a_CAP_trade-off https://en.wikipedia.org/wiki/Consistency_(database_systems)... Postgresql with read replicas is ACID-Consistent transactions because single writer, and CAP-AP eventually consistent because distributed reads. It is easy to agree with you here: "PostgreSQL basically stops working well too, once you start mixing transaction processing and business reporting and BI in the same box at scale." It's worse than that - the app has to be coded before it can be scaled so you get fucked by complexity-scale via ORM a lot sooner than bigdata-scale. But as you sort of say, the point of a data warehouse is to be cap-AP (eventually consistent) through read-replicas without breaking ACID-consistent transactions for the system as a whole. as to the argument "everything is bad at scale" i think that has merit too, I just gave a talk at ClojureNYC about building real apps with Postgres (tables) vs Neo4J (graph) vs Mongo (documents) vs Datomic (eavt): https://github.com/hyperfiddle/hypercrud.browser/issues/4 https://github.com/hyperfiddle/hypercrud.browser/issues/4 (Did I say real "apps"? I meant "balls of mud")
- elvinyung 9y ago
  IMO, as I've said elsewhere on this thread, I really don't think it's useful to talk about the C-in-ACID and the C-in-CAP as if they were completely different things. The original research (both Gray's and Brewer's) clearly talks about it in terms of interface guarantees on your data, and the latter is directly built upon the former. As a user, all I care about is that the new data shows up once the system accepts it, no buts. What good is my Postgres single-node ACID if I have to do all this work to deal with replication lag?
  - dustingetz 9y ago
    What good is ACID writes with AP reads? It doesn't lose data! Don't like eventual consistency? You have options! Check out Datomic - ACID transactions and strongly consistent + distributed reads. http://www.datomic.com/ http://www.datomic.com/ Git is another ACID single-writer system with strong consistency and distributed reads.
bpicolo 9y ago
> business reporting and BI in the same box at scale. To be fair, it's an easy win to throw a replica in the mix with no downsides for BI. Not to mention, BI at scale tends to send data to redshift or the like first

dustingetz 9y ago

ACID's C is about the write side: "ACID is a set of properties of database transactions" (wikipedia) which is different than CAP's C: https://en.wikipedia.org/wiki/Consistency_(database_systems)#As_a_CAP_trade-off https://en.wikipedia.org/wiki/Consistency_(database_systems)... Postgresql with read replicas is ACID-Consistent transactions because single writer, and CAP-AP eventually consistent because distributed reads. It is easy to agree with you here: "PostgreSQL basically stops working well too, once you start mixing transaction processing and business reporting and BI in the same box at scale." It's worse than that - the app has to be coded before it can be scaled so you get fucked by complexity-scale via ORM a lot sooner than bigdata-scale. But as you sort of say, the point of a data warehouse is to be cap-AP (eventually consistent) through read-replicas without breaking ACID-consistent transactions for the system as a whole. as to the argument "everything is bad at scale" i think that has merit too, I just gave a talk at ClojureNYC about building real apps with Postgres (tables) vs Neo4J (graph) vs Mongo (documents) vs Datomic (eavt): https://github.com/hyperfiddle/hypercrud.browser/issues/4 https://github.com/hyperfiddle/hypercrud.browser/issues/4 (Did I say real "apps"? I meant "balls of mud")

elvinyung 9y ago
IMO, as I've said elsewhere on this thread, I really don't think it's useful to talk about the C-in-ACID and the C-in-CAP as if they were completely different things. The original research (both Gray's and Brewer's) clearly talks about it in terms of interface guarantees on your data, and the latter is directly built upon the former. As a user, all I care about is that the new data shows up once the system accepts it, no buts. What good is my Postgres single-node ACID if I have to do all this work to deal with replication lag?
- dustingetz 9y ago
  What good is ACID writes with AP reads? It doesn't lose data! Don't like eventual consistency? You have options! Check out Datomic - ACID transactions and strongly consistent + distributed reads. http://www.datomic.com/ http://www.datomic.com/ Git is another ACID single-writer system with strong consistency and distributed reads.

bpicolo 9y ago

> business reporting and BI in the same box at scale. To be fair, it's an easy win to throw a replica in the mix with no downsides for BI. Not to mention, BI at scale tends to send data to redshift or the like first