4 ms·

I have been told that MySQL / MariaDB is significantly more scalable than Postgres, although I expect that opinion is based on old data. I don't have firsthand

I have been told that MySQL / MariaDB is significantly more scalable than Postgres, although I expect that opinion is based on old data. I don't have firsthand knowledge of this, so I can't comment further. Came to the comments to see if anyone knowledgeable would react to that point. (maybe they can reply here :) )

kstrauser 5y ago
Last I heard, it's the opposite: MySQL/MariaDB might be faster for single connections, but PostgreSQL can be much faster for heavy workloads. For instance, PostgreSQL added a feature to support sharing table scans between multiple connections. Suppose you have a million rows in a table "foo". - Connection 1 executes "select * from foo". It begins at row 1 and starts a table scan. - When the reader is at row 500,000, connection 2 executes "select * from foo". It starts returning results beginning at row 500,000, so both connections are sharing the output of the reader. - When the reader gets to row 1,000,000, the first query is finished. It's seen all the rows. The reader starts back at row 1, and continues feeding results to the second query until it gets back to run 499,999. Then the second query is also finished. Even though 2 queries were running, the DB backend was only doing the work of 1. With that setup, you could have 100 "select * from foo" queries running simultaneously without increasing the database load at all. I don't know if MySQL supports that kind of thing now. In any case, that's an example of some of the incredible engineering PostgreSQL uses to be correct and fast.
- isotopp 5y ago
  If, in a customer facing database, you have to table scan, you have already lost. For data warehouses this is a different story, but god help you if you are table scanning in OLTP context.
- CRConrad 5y ago
  Even though 2 queries were running, the DB backend was only doing the work of 1. Well, one and a half. Or the work of one query, but one and a half times.

kstrauser 5y ago

Last I heard, it's the opposite: MySQL/MariaDB might be faster for single connections, but PostgreSQL can be much faster for heavy workloads. For instance, PostgreSQL added a feature to support sharing table scans between multiple connections. Suppose you have a million rows in a table "foo". - Connection 1 executes "select * from foo". It begins at row 1 and starts a table scan. - When the reader is at row 500,000, connection 2 executes "select * from foo". It starts returning results beginning at row 500,000, so both connections are sharing the output of the reader. - When the reader gets to row 1,000,000, the first query is finished. It's seen all the rows. The reader starts back at row 1, and continues feeding results to the second query until it gets back to run 499,999. Then the second query is also finished. Even though 2 queries were running, the DB backend was only doing the work of 1. With that setup, you could have 100 "select * from foo" queries running simultaneously without increasing the database load at all. I don't know if MySQL supports that kind of thing now. In any case, that's an example of some of the incredible engineering PostgreSQL uses to be correct and fast.

isotopp 5y ago
If, in a customer facing database, you have to table scan, you have already lost. For data warehouses this is a different story, but god help you if you are table scanning in OLTP context.
CRConrad 5y ago
Even though 2 queries were running, the DB backend was only doing the work of 1. Well, one and a half. Or the work of one query, but one and a half times.