3 ms·

Use MySQL if you're expecting to have to do large operational database tasks re: migrations, maintenances, with no ability to go offline. gh-ost, percona-osc, t

Use MySQL if you're expecting to have to do large operational database tasks re: migrations, maintenances, with no ability to go offline. gh-ost, percona-osc, the new INSTANT DDL stuff, is all quite far ahead in MySQL-land. Additionally, Vitess and Planetscale are making huge strides in MySQL performance. There are more people and guides in the world to help recover even the most mutilated of MySQL databases. MySQL gets more love in extremely large enterprise-level organizations, and it shows. Use Postgres if you need some of the quite-good extensions, most notably PostGIS, or if you just want things to work; most documentation will be postgres flavored. Postgres gets more love from web-developers, and it shows.

fzeindl 3y ago
This is wrong. MySQL does not support transactional DDL, so you cannot run migration and abort them in the middle. Always use postgresql. It's more logical, more extensible, saner, supports many extensions and is more predictable. MySQL is inconsistent crap, that trades away consistency, correctness and stability for a little bit of performance in standard use cases. Do yourself a favor and always use postgreSQL. I switched 15 years ago and never looked back. Have done 15-50 projects since in psql.
- deleted 3y ago
  [deleted]
- amflare 3y ago
  Spoken like someone who switched 15 years ago and never looked back.
- WJW 3y ago
  With a sane migration tool like pt-osc or gh-ost you can absolutely abort in the middle. What's more, you can pause in the middle or even slow down in the middle based on arbitrary logic (ie, pause migration if replication delay rises above a certain value). Postgres is nice and transactional DDL has its place but postgres stopped halfway through IMO. Vanilla Postgres > vanilla MySQL, but the migration story of MySQL + tooling is so far beyond Postgres + tooling that it's not even funny. That said, if you don't expect to have tables with 100m+ rows, even vanilla postgres will be good enough.
- barrkel 3y ago
  Production MySQL databases of any significant size use pt-osc or gh-ost for schema changes, and these can be throttled, paused, aborted and so on.

fzeindl 3y ago

This is wrong. MySQL does not support transactional DDL, so you cannot run migration and abort them in the middle. Always use postgresql. It's more logical, more extensible, saner, supports many extensions and is more predictable. MySQL is inconsistent crap, that trades away consistency, correctness and stability for a little bit of performance in standard use cases. Do yourself a favor and always use postgreSQL. I switched 15 years ago and never looked back. Have done 15-50 projects since in psql.

deleted 3y ago
[deleted]
amflare 3y ago
Spoken like someone who switched 15 years ago and never looked back.
WJW 3y ago
With a sane migration tool like pt-osc or gh-ost you can absolutely abort in the middle. What's more, you can pause in the middle or even slow down in the middle based on arbitrary logic (ie, pause migration if replication delay rises above a certain value). Postgres is nice and transactional DDL has its place but postgres stopped halfway through IMO. Vanilla Postgres > vanilla MySQL, but the migration story of MySQL + tooling is so far beyond Postgres + tooling that it's not even funny. That said, if you don't expect to have tables with 100m+ rows, even vanilla postgres will be good enough.
barrkel 3y ago
Production MySQL databases of any significant size use pt-osc or gh-ost for schema changes, and these can be throttled, paused, aborted and so on.