9 ms·

There is almost no good reason to choose MySQL over PostgreSQL for any operational reason, I did a deep dive many moons ago (before major improvements in perfor

by dijit 4y ago

There is almost no good reason to choose MySQL over PostgreSQL for any operational reason, I did a deep dive many moons ago (before major improvements in performance to postgres) and people were saying that MySQL was faster. I found that not to be true and the differences have only gained even more favour towards postgres. also, I assume you mean MariaDB as MySQL is owned by Oracle and I would greatly implore anyone and everyone to avoid Oracle as if it has herpes. There are a lot of historic problems with MySQL accepting invalid data, committing data even when there are constraint issues, and having very poor transactional isolation, I am not sure if these have improved. Truthfully, the only benefits you gain from using MariaDB or MySQL are: * Memory tables * Having inconsistent replicas (which can be useful when you want your downstream to have less data than your upstream and you know it won’t get updated.)

noodlesUK 4y ago
I think that the only reasons to choose MySQL (or Maria) over Postgres for a new project are operational. Postgres is probably the better database in almost all respects, but major version upgrades are much much more of a pain on Postgres than on almost any other system I have ever used. That being said, I would choose Postgres pretty much every time for a new project. The only reason I would use Maria or MySQL would be if I thought I later would want to have something like Vitess, for which I think there isn't really an equivalent for Postgres.
- dijit 4y ago
  > but major version upgrades are much much more of a pain on Postgres than on almost any other system I have ever used. This is a thread comparing MySQL and Postgres and your claim is that postgres is harder to do major version upgrades than anything you have used?? Context is important here, have you honestly actually upgraded a MySQL node? It’s a lesson in pain and “major” version changes happen on minor versions, like the entire query planner completely trashing performance in 5.6->5.7 Postgres has two forms of updates: 1) in place binary upgrade. Fast, clean, simple, requires that you have the binaries for the old and the new database. 2) dump/restore. Serialise the database into text files, load a new database and deserialise those files into it. Slow, but works flawlessly & consistently with relatively low danger. MySQL can only do option 2. You can sort of fake an “update” by abusing the fact that MYSQLs replication offers no guarantees, so you can make a new server a replica; then roll over. But it is impossible to know what data was lost in that transition and MySQL will happily continue without ever telling you. I have experienced this behaviour in large e-commerce retailers. MySQL was very popular for a very long time and I am intimately aware of operational best practices and how they are merely patching over an insane system.
  - evanelias 4y ago
    MySQL doesn't use SemVer. MySQL 5.6 vs 5.7 are different "release series", and switching between them is considered a "major" version change. MySQL absolutely fully supports in-place binary upgrades, saying otherwise is pure FUD. And the upgrade process in MySQL doesn't even iterate over your table data in any way, so claiming it will cause "data loss" is also pure FUD. At Facebook we automated rolling in-place updates of our entire fleet, with new point builds of fb-mysql going out several times a month, to the largest MySQL deployment in the world. Worked flawlessly and this was a full decade ago. MySQL is widely considered easier to upgrade (relative to Postgres) because MySQL's built-in replication has always been logical replication. Replicating from an older-version primary to a newer-version replica is fully supported. When upgrading a replica set, the usual dance is "upgrade the replicas in-place one at a time, promote one of the replicas to be the new primary while temporarily booting out the old primary; upgrade the old primary and then rejoin the replica set".
    - dijit 4y ago
      Facebook has, at minimum, 3 teams maintaining MySQL. including a team who genuinely modifies it into submission. so much that they needed 1,700 patches to port their modified version to 8.0. It is not relevant to the discussion to discuss how Facebook has managed to munge it to work reasonably well by pouring thousands of hours of engineer time into the effort; and MySQLs in-place upgrades absolutely do not work the way you describe consistently. I know this because I have been in the code, and only after having experienced it. Maybe some of your lovely colleagues has helped out your particular version to be marginally more sane. It genuinely must be nice having a dozen people who can work around these issues though, I certainly wouldn’t consider it an operational win, most companies have no DB automation engineers, or DB performance engineers or MySQL infrastructure engineers. > Replicating from an older-version primary to a newer-version replica is fully supported. Here also be dragons, as eluded to. I know it works quite often, I have used it. FWIW: I ran global AAA online-only game profile systems on a handful of Postgres machines at about 120k transactions/s in 2016, I would have needed 5x as many instances to do it in MySQL, and this was only tiny part of our hosted infra.. which included a global edge deployment of game servers, auth servers, matchmaking, voice bridges and so on. and we only had two people responsible for the entire operation
otabdeveloper4 4y ago
Does Postgres have binlog replication yet?
- dijit 4y ago
  Yes, for over half a decade at least, but “binlog” is a MySQL term, for postgresql it has the much more apt name: write-ahead log. it is the only official, in-binary replication mechanism.
  - evanelias 4y ago
    Postgres WAL replication is a physical replication stream. MySQL binlog replication is a logical replication stream, a higher-level abstraction which is independent of the storage engines. Postgres does separately support logical replication now, but it has some limitations, such as not permitting replication of DDL: https://www.postgresql.org/docs/current/logical-replication-restrictions.html https://www.postgresql.org/docs/current/logical-replication-...
LammyL 4y ago
Is there a good way to do case-insensitive accent-insensitive collations yet in postgresql? It’s been a holdup for using that for some use cases like searching for data, like a person’s name, in pgsql when the casing or accents don’t match perfectly. Mssql has had this for ever, and I’m pretty sure MySQL has it as well.
- dijit 4y ago
  Maybe this helps: https://stackoverflow.com/posts/11007216/revisions https://stackoverflow.com/posts/11007216/revisions ? My gut tells me that I would do it in the query itself though, and not rely on the collation. Maybe I am misunderstanding.
  - sjamaan 4y ago
    Look under "Update for Postgres 12 or later", there they create a collation, an index to make use of it and then a query to make use of it: SELECT \* FROM users WHERE name = 'João' COLLATE ignore_accent;
- EwanToo 4y ago
  Not really, no, it's doable but not easily
pyuser583 4y ago
Does Postgres have an archive mode?
- dijit 4y ago
  If you say what you’re trying to actually achieve I can help with a solution, but asking if it supports an arbitrary feature is not going to get the answer you want because depending on what you’re actually using an archive table for, Postgres might have something already built in but it will almost assuredly not be exactly like an archive table storage type.
  - pyuser583 4y ago
    Sorry, ARCHIVE is a MySQL storage engine. It supports only non destructive transactions: INSERT, REPLACE, and SELECT, but not DELETE and UPDATE. It’s an excellent alternative to use a WORM drive when you’re trying to preserve everything (say, a list of financial transaction). I’ve looked for something like this in Postgres (which I love!), but sadly it doesn’t seem supported. https://dev.mysql.com/doc/refman/8.0/en/archive-storage-engine.html https://dev.mysql.com/doc/refman/8.0/en/archive-storage-engi...
    - ants_a 4y ago
      Why is revoking permissions to run deletes/updates not an option?
      - deleted 4y ago
        [deleted]
    - yencabulator 4y ago
      Saying that REPLACE is non-destructive is a bit weird. Overwriting data is destructive, by definition -- and even if ARCHIVE is append-only underneath, it seems this use of REPLACE is very much a "logical overwrite", as there doesn't seem to be any kind of time travel view of the old state. Also, you might be interested in Parquet, perhaps as seen through Delta Lake https://delta.io/ https://delta.io/ or Postgres Foreign Data Wrappers like https://github.com/adjust/parquet_fdw https://github.com/adjust/parquet_fdw -- Delta Lake's simple "LSM of Parquet files in an object store" design is pretty sweet.
0xbadcafebee 4y ago
> avoid Oracle as if it has herpes herpes isn't that bad. most people will get it in their lifetime. 1 in 6 people have hsv-2, the less common variant. trying to avoid herpes is like trying to avoid chickenpox (although herpes isn't nearly as harmful as chickenpox). you should avoid Oracle like it's a blood pathogen.
- unethical_ban 4y ago
  hello, fellow person with herpes! (I assume) The worst part about having it is having to talk about having it. It's really not bad as a condition separate from societal concern.
  - stavros 4y ago
    I find similar societal concern when I tell friends I use Oracle.
    - r2_pilot 4y ago
      Having Oracle experience on the resume is a positive, I suppose, but I'm not sure it's been worth the exposure.
  - enneff 4y ago
    It’s not so bad for most people but if you’re one of the unfortunate few who suffer chronic symptoms it can be truly awful. Not worth playing that lottery if you can avoid it.
- deleted 4y ago
  [deleted]
- soperj 4y ago
  Chickenpox is actually caused by a herpesvirus. herpes varicella zoster.
- za3faran 4y ago
  > most people will get it in their lifetime Citation needed.
srcreigh 4y ago
Postgres is >50x slower for range queries(example below) and is akin to using array-of-pointers (ie Java) whereas MySQL supports array-of-struct (C). Illustration from Dropbox scaling talk below. Sneak peek photo [1] (from [2]). Just imagine its literally 500-1000x more convoluted per B-tree leaf node. That's every Postgres table unless you CLUSTER periodically. [1]: https://josipmisko.com/img/clustered-vs-nonclustered-index.webp https://josipmisko.com/img/clustered-vs-nonclustered-index.w... [2]: https://josipmisko.com/posts/clustered-vs-non-clustered-index https://josipmisko.com/posts/clustered-vs-non-clustered-inde... Mind boggling how many people aren't aware of primary indexes in MySQL that is not supported at all in Postgres. For certain data layouts, Postgres pays either 2x storage (covering index containing every single column), >50x worse performance by effectively N+1 bombing the disk for range queries, or blocking your table periodically (CLUSTER). In Postgres the messiness loading primary data after reaching the B-tree leaf nodes pollutes caches and takes longer. This is because you need to load one 8kb page for every row you want, instead of one 8kb with 20-30 rows packed together. Example: Dropbox file history table. They initially used autoinc id for primary key in MySQL. This causes everybodys file changes to be mixed together in chronological order on disk in a B-Tree. The first optimization they made was to change the primary key to (ns_id, latest, id) so that each users (ns_id) latest versions would be grouped together on disk. Dropbox scaling talk: https://youtu.be/PE4gwstWhmc?t=2770 https://youtu.be/PE4gwstWhmc?t=2770 If a dropbox user has 1000 files and you can fit 20 file-version rows on each 8kb disk page (400bytes/row), the difference in performance for querying across those 1000 files is 20 + logN disk reads (MySQL) vs 1000 + logN disk reads (Postgres). AKA 400KiB data loaded (MySQL) vs 8.42MiB loaded (Postgres). AKA >50x improvement in query time and disk page cache utilization. In Postgres you get two bad options for doing this: 1) Put every row of the table in the index making it a covering index, and paying to store all data twice (index and PG heap). No way to disable the heap primary storage. 2) Take your DB offline every day and CLUSTER the table. Realistically, PG users pay that 50x cost without thinking about it. Any time you query a list of items in PG even using an index, you're N+1 querying against your disk and polluting your cache. This is why MySQL is faster than Postgres most of the time. Hopefully more people become aware of disk data layout and how it affects query performance. There is a hack for Postgres where you store data in an array within the row. This puts the data contiguously on disk. It works pretty well, sometimes, but it’s hacky. This strategy is part of the Timescale origin story. Open to db perf consulting. email is in my profile.
za3faran 4y ago
MySQL is free, regardless of Oracle's ownership.
asdfman123 4y ago
The main problem with herpes is the stigma against it. Don't besmirch it by associating with Oracle.
eyelidlessness 4y ago
The only reason I’d consider MariaDB, which I’m surprised I don’t see mentioned currently, is its bitemporal features. There are whole worlds of problems solved that are almost universally badly done in schema/business logic instead. Granted I haven’t had to make a decision like this for several years, I’ve hardly even touched a database except to debug some stuff on localhost that’s outside of my explicit purview. So maybe Postgres solutions have narrowed the gap on this without my knowing it.
paulddraper 4y ago
MySQL is certainly faster for writes. https://www.uber.com/blog/postgres-to-mysql-migration/ https://www.uber.com/blog/postgres-to-mysql-migration/
- arp242 4y ago
  I would be wary putting too much stock in a seven year old post on the topic; lots of stuff has changed. Specifically, at least one person claimed that a patch greatly improved PostgreSQL for this use case: https://news.ycombinator.com/item?id=26285452 https://news.ycombinator.com/item?id=26285452
  - paulddraper 4y ago
    The MVCC requirement is still there. It's like saying C is faster than Ruby. It always will be.
supergram 4y ago
> * Memory tables PostgreSQL has memory tables too.
throw0101b 4y ago
> There is almost no good reason to choose MySQL over PostgreSQL for any operational reason Galera is the main one I can think of: * https://galeracluster.com/library/documentation/tech-desc-introduction.html https://galeracluster.com/library/documentation/tech-desc-in... * https://mariadb.com/kb/en/what-is-mariadb-galera-cluster/ https://mariadb.com/kb/en/what-is-mariadb-galera-cluster/ * https://packages.debian.org/search?keywords=galera https://packages.debian.org/search?keywords=galera I'm not aware of any multi-master, active-active(-active) replication system that is open source for PostgreSQL.
- jaachan 4y ago
  We ran a Galera cluster for 4 days and it died on the first ALTER TABLE we did. Only option was to reduce it down to a Primary / Replica setup. I really can't recommend anyone using this.
- dijit 4y ago
  Last time I looked at Galera it had a limit at 5TiB of data. Which is fine I guess. In the Postgres space there is citusdb which provides multi master. There is also BDR from 2ndquadrant if you want a paid/supported solution. https://www.enterprisedb.com/products/edb-postgres-distributed https://www.enterprisedb.com/products/edb-postgres-distribut...
- davidgerard 4y ago
  yeah, that's the use case "I run an application that requires or is highly optimised for MySQL".
- avinassh 4y ago
  how do multi master MySQL handles conflicts?

by dijit 4y ago

noodlesUK 4y ago

I think that the only reasons to choose MySQL (or Maria) over Postgres for a new project are operational. Postgres is probably the better database in almost all respects, but major version upgrades are much much more of a pain on Postgres than on almost any other system I have ever used. That being said, I would choose Postgres pretty much every time for a new project. The only reason I would use Maria or MySQL would be if I thought I later would want to have something like Vitess, for which I think there isn't really an equivalent for Postgres.

dijit 4y ago
> but major version upgrades are much much more of a pain on Postgres than on almost any other system I have ever used. This is a thread comparing MySQL and Postgres and your claim is that postgres is harder to do major version upgrades than anything you have used?? Context is important here, have you honestly actually upgraded a MySQL node? It’s a lesson in pain and “major” version changes happen on minor versions, like the entire query planner completely trashing performance in 5.6->5.7 Postgres has two forms of updates: 1) in place binary upgrade. Fast, clean, simple, requires that you have the binaries for the old and the new database. 2) dump/restore. Serialise the database into text files, load a new database and deserialise those files into it. Slow, but works flawlessly & consistently with relatively low danger. MySQL can only do option 2. You can sort of fake an “update” by abusing the fact that MYSQLs replication offers no guarantees, so you can make a new server a replica; then roll over. But it is impossible to know what data was lost in that transition and MySQL will happily continue without ever telling you. I have experienced this behaviour in large e-commerce retailers. MySQL was very popular for a very long time and I am intimately aware of operational best practices and how they are merely patching over an insane system.
- evanelias 4y ago
  MySQL doesn't use SemVer. MySQL 5.6 vs 5.7 are different "release series", and switching between them is considered a "major" version change. MySQL absolutely fully supports in-place binary upgrades, saying otherwise is pure FUD. And the upgrade process in MySQL doesn't even iterate over your table data in any way, so claiming it will cause "data loss" is also pure FUD. At Facebook we automated rolling in-place updates of our entire fleet, with new point builds of fb-mysql going out several times a month, to the largest MySQL deployment in the world. Worked flawlessly and this was a full decade ago. MySQL is widely considered easier to upgrade (relative to Postgres) because MySQL's built-in replication has always been logical replication. Replicating from an older-version primary to a newer-version replica is fully supported. When upgrading a replica set, the usual dance is "upgrade the replicas in-place one at a time, promote one of the replicas to be the new primary while temporarily booting out the old primary; upgrade the old primary and then rejoin the replica set".
  - dijit 4y ago
    Facebook has, at minimum, 3 teams maintaining MySQL. including a team who genuinely modifies it into submission. so much that they needed 1,700 patches to port their modified version to 8.0. It is not relevant to the discussion to discuss how Facebook has managed to munge it to work reasonably well by pouring thousands of hours of engineer time into the effort; and MySQLs in-place upgrades absolutely do not work the way you describe consistently. I know this because I have been in the code, and only after having experienced it. Maybe some of your lovely colleagues has helped out your particular version to be marginally more sane. It genuinely must be nice having a dozen people who can work around these issues though, I certainly wouldn’t consider it an operational win, most companies have no DB automation engineers, or DB performance engineers or MySQL infrastructure engineers. > Replicating from an older-version primary to a newer-version replica is fully supported. Here also be dragons, as eluded to. I know it works quite often, I have used it. FWIW: I ran global AAA online-only game profile systems on a handful of Postgres machines at about 120k transactions/s in 2016, I would have needed 5x as many instances to do it in MySQL, and this was only tiny part of our hosted infra.. which included a global edge deployment of game servers, auth servers, matchmaking, voice bridges and so on. and we only had two people responsible for the entire operation

otabdeveloper4 4y ago

Does Postgres have binlog replication yet?

dijit 4y ago
Yes, for over half a decade at least, but “binlog” is a MySQL term, for postgresql it has the much more apt name: write-ahead log. it is the only official, in-binary replication mechanism.
- evanelias 4y ago
  Postgres WAL replication is a physical replication stream. MySQL binlog replication is a logical replication stream, a higher-level abstraction which is independent of the storage engines. Postgres does separately support logical replication now, but it has some limitations, such as not permitting replication of DDL: https://www.postgresql.org/docs/current/logical-replication-restrictions.html https://www.postgresql.org/docs/current/logical-replication-...

LammyL 4y ago

Is there a good way to do case-insensitive accent-insensitive collations yet in postgresql? It’s been a holdup for using that for some use cases like searching for data, like a person’s name, in pgsql when the casing or accents don’t match perfectly. Mssql has had this for ever, and I’m pretty sure MySQL has it as well.

dijit 4y ago
Maybe this helps: https://stackoverflow.com/posts/11007216/revisions https://stackoverflow.com/posts/11007216/revisions ? My gut tells me that I would do it in the query itself though, and not rely on the collation. Maybe I am misunderstanding.
- sjamaan 4y ago
  Look under "Update for Postgres 12 or later", there they create a collation, an index to make use of it and then a query to make use of it: SELECT \* FROM users WHERE name = 'João' COLLATE ignore_accent;
EwanToo 4y ago
Not really, no, it's doable but not easily

pyuser583 4y ago

Does Postgres have an archive mode?

dijit 4y ago
If you say what you’re trying to actually achieve I can help with a solution, but asking if it supports an arbitrary feature is not going to get the answer you want because depending on what you’re actually using an archive table for, Postgres might have something already built in but it will almost assuredly not be exactly like an archive table storage type.
- pyuser583 4y ago
  Sorry, ARCHIVE is a MySQL storage engine. It supports only non destructive transactions: INSERT, REPLACE, and SELECT, but not DELETE and UPDATE. It’s an excellent alternative to use a WORM drive when you’re trying to preserve everything (say, a list of financial transaction). I’ve looked for something like this in Postgres (which I love!), but sadly it doesn’t seem supported. https://dev.mysql.com/doc/refman/8.0/en/archive-storage-engine.html https://dev.mysql.com/doc/refman/8.0/en/archive-storage-engi...
  - ants_a 4y ago
    Why is revoking permissions to run deletes/updates not an option?
    - deleted 4y ago
      [deleted]
  - yencabulator 4y ago
    Saying that REPLACE is non-destructive is a bit weird. Overwriting data is destructive, by definition -- and even if ARCHIVE is append-only underneath, it seems this use of REPLACE is very much a "logical overwrite", as there doesn't seem to be any kind of time travel view of the old state. Also, you might be interested in Parquet, perhaps as seen through Delta Lake https://delta.io/ https://delta.io/ or Postgres Foreign Data Wrappers like https://github.com/adjust/parquet_fdw https://github.com/adjust/parquet_fdw -- Delta Lake's simple "LSM of Parquet files in an object store" design is pretty sweet.

0xbadcafebee 4y ago

> avoid Oracle as if it has herpes herpes isn't that bad. most people will get it in their lifetime. 1 in 6 people have hsv-2, the less common variant. trying to avoid herpes is like trying to avoid chickenpox (although herpes isn't nearly as harmful as chickenpox). you should avoid Oracle like it's a blood pathogen.

unethical_ban 4y ago
hello, fellow person with herpes! (I assume) The worst part about having it is having to talk about having it. It's really not bad as a condition separate from societal concern.
- stavros 4y ago
  I find similar societal concern when I tell friends I use Oracle.
  - r2_pilot 4y ago
    Having Oracle experience on the resume is a positive, I suppose, but I'm not sure it's been worth the exposure.
- enneff 4y ago
  It’s not so bad for most people but if you’re one of the unfortunate few who suffer chronic symptoms it can be truly awful. Not worth playing that lottery if you can avoid it.
deleted 4y ago
[deleted]
soperj 4y ago
Chickenpox is actually caused by a herpesvirus. herpes varicella zoster.
za3faran 4y ago
> most people will get it in their lifetime Citation needed.

srcreigh 4y ago

Postgres is >50x slower for range queries(example below) and is akin to using array-of-pointers (ie Java) whereas MySQL supports array-of-struct (C). Illustration from Dropbox scaling talk below. Sneak peek photo [1] (from [2]). Just imagine its literally 500-1000x more convoluted per B-tree leaf node. That's every Postgres table unless you CLUSTER periodically. [1]: https://josipmisko.com/img/clustered-vs-nonclustered-index.webp https://josipmisko.com/img/clustered-vs-nonclustered-index.w... [2]: https://josipmisko.com/posts/clustered-vs-non-clustered-index https://josipmisko.com/posts/clustered-vs-non-clustered-inde... Mind boggling how many people aren't aware of primary indexes in MySQL that is not supported at all in Postgres. For certain data layouts, Postgres pays either 2x storage (covering index containing every single column), >50x worse performance by effectively N+1 bombing the disk for range queries, or blocking your table periodically (CLUSTER). In Postgres the messiness loading primary data after reaching the B-tree leaf nodes pollutes caches and takes longer. This is because you need to load one 8kb page for every row you want, instead of one 8kb with 20-30 rows packed together. Example: Dropbox file history table. They initially used autoinc id for primary key in MySQL. This causes everybodys file changes to be mixed together in chronological order on disk in a B-Tree. The first optimization they made was to change the primary key to (ns_id, latest, id) so that each users (ns_id) latest versions would be grouped together on disk. Dropbox scaling talk: https://youtu.be/PE4gwstWhmc?t=2770 https://youtu.be/PE4gwstWhmc?t=2770 If a dropbox user has 1000 files and you can fit 20 file-version rows on each 8kb disk page (400bytes/row), the difference in performance for querying across those 1000 files is 20 + logN disk reads (MySQL) vs 1000 + logN disk reads (Postgres). AKA 400KiB data loaded (MySQL) vs 8.42MiB loaded (Postgres). AKA >50x improvement in query time and disk page cache utilization. In Postgres you get two bad options for doing this: 1) Put every row of the table in the index making it a covering index, and paying to store all data twice (index and PG heap). No way to disable the heap primary storage. 2) Take your DB offline every day and CLUSTER the table. Realistically, PG users pay that 50x cost without thinking about it. Any time you query a list of items in PG even using an index, you're N+1 querying against your disk and polluting your cache. This is why MySQL is faster than Postgres most of the time. Hopefully more people become aware of disk data layout and how it affects query performance. There is a hack for Postgres where you store data in an array within the row. This puts the data contiguously on disk. It works pretty well, sometimes, but it’s hacky. This strategy is part of the Timescale origin story. Open to db perf consulting. email is in my profile.

za3faran 4y ago

MySQL is free, regardless of Oracle's ownership.

asdfman123 4y ago

The main problem with herpes is the stigma against it. Don't besmirch it by associating with Oracle.

eyelidlessness 4y ago

The only reason I’d consider MariaDB, which I’m surprised I don’t see mentioned currently, is its bitemporal features. There are whole worlds of problems solved that are almost universally badly done in schema/business logic instead. Granted I haven’t had to make a decision like this for several years, I’ve hardly even touched a database except to debug some stuff on localhost that’s outside of my explicit purview. So maybe Postgres solutions have narrowed the gap on this without my knowing it.

paulddraper 4y ago

MySQL is certainly faster for writes. https://www.uber.com/blog/postgres-to-mysql-migration/ https://www.uber.com/blog/postgres-to-mysql-migration/

arp242 4y ago
I would be wary putting too much stock in a seven year old post on the topic; lots of stuff has changed. Specifically, at least one person claimed that a patch greatly improved PostgreSQL for this use case: https://news.ycombinator.com/item?id=26285452 https://news.ycombinator.com/item?id=26285452
- paulddraper 4y ago
  The MVCC requirement is still there. It's like saying C is faster than Ruby. It always will be.

supergram 4y ago

> * Memory tables PostgreSQL has memory tables too.

throw0101b 4y ago

> There is almost no good reason to choose MySQL over PostgreSQL for any operational reason Galera is the main one I can think of: * https://galeracluster.com/library/documentation/tech-desc-introduction.html https://galeracluster.com/library/documentation/tech-desc-in... * https://mariadb.com/kb/en/what-is-mariadb-galera-cluster/ https://mariadb.com/kb/en/what-is-mariadb-galera-cluster/ * https://packages.debian.org/search?keywords=galera https://packages.debian.org/search?keywords=galera I'm not aware of any multi-master, active-active(-active) replication system that is open source for PostgreSQL.

jaachan 4y ago
We ran a Galera cluster for 4 days and it died on the first ALTER TABLE we did. Only option was to reduce it down to a Primary / Replica setup. I really can't recommend anyone using this.
dijit 4y ago
Last time I looked at Galera it had a limit at 5TiB of data. Which is fine I guess. In the Postgres space there is citusdb which provides multi master. There is also BDR from 2ndquadrant if you want a paid/supported solution. https://www.enterprisedb.com/products/edb-postgres-distributed https://www.enterprisedb.com/products/edb-postgres-distribut...
davidgerard 4y ago
yeah, that's the use case "I run an application that requires or is highly optimised for MySQL".
avinassh 4y ago
how do multi master MySQL handles conflicts?