The ProxySQL team writes about its MySQL and PostgreSQL proxy, covering scaling, query caching, ClickHouse integration, and comparisons with other proxies.
HN commenters call ProxySQL powerful and battle-tested, widely used at scale, and one reports years without downtime.
> replication options like multi-source
MySQL 5.7 supports multi-source replication:
https://dev.mysql.com/doc/refman/5.7/en/replication-channels.html
> spider for sharding and galera are all built in and actively maintained.
Galera is available in MySQL-compatible binaries from Percona (Percona-XtraDB-Cluster): https://www.percona.com/software/mysql-database/percona-xtradb-cluster
MySQL also has their own Paxos-compliant clustering solution (called "Innodb cluster"), first available in 5.7, but much better in 8.0:
https://dev.mysql.com/doc/refman/5.7/en/mysql-innodb-cluster-introduction.html
I played with Spider in MariaDB 10.3, and it didn't satisfy the requirements we had, and it doesn't seem to have progressed significantly since then.
Yes, it's neat that MariaDB merged it and is keeping it working, but there don't seem to be many use cases where it ends up being significantly better than e.g. multi-source replication (the use cases where you're going to run out of disk, in most cases spider's un-implemented push-down join etc. make it too slow to be practical either).
> Online schema changes,
https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html
(including "instant column add")
> easy horizontal scale (huge numbers that make db2 and oracle sweat), s3 backed tables, non blocking backups,
MySQL has had "MySQL Enterprise Backup" for a long time. Percona wrote a similar implementation (XtraBackup), which works for MySQL, Percona, and MariaDB.…
I don't think the claim of MySQL replication being better is related to statement vs. row vs. binary diff. I think it is about the tooling and community knowledge about replication, and about running MySQL in large scale production environments in general.
MySQL is run more often at extremely large scale (Facebook, YouTube, Twitter, Dropbox, etc.) than Postgres. That results in very battle tested and/or featureful tooling like orchestrator (https://github.com/github/orchestrator), MHA (https://github.com/yoshinorim/mha4mysql-manager), ProxySQL (http://www.proxysql.com/), and gh-ost (https://github.com/github/gh-ost), along knowledge and best practices shared by those organization.
note that while the MySQL connection-pool equation is pretty different from that of Postgresql's, at least in my experience MySQL connections use less memory (sorry, no measurements handy, feel free to correct me, but they generally are handled as a thread rather than an entire subprocess and we regularly see apps that spin up thousands of them fairly cheaply) and also have a lower startup time (also anecdotal, sorry), the MySQL world does finally have middleware connection pools now such as proxysql: https://proxysql.com/
Also check out ProxySQL [1][2], it's an extremely powerful and battle-tested proxy. Originally it was only for MySQL/MariaDB, where it is very widely used at scale, even despite MySQL already having excellent built-in scalable threaded connection management. But ProxySQL also added Postgres support too in 2024 and that has become a major focus.
[1] https://proxysql.com/
[2] https://github.com/sysown/proxysql
> 3. Use a bouncer which can either disallow these changes or detect and revert them after the original client has disconnected. I'm not sure if this exists for MySQL at least.
I believe ProxySQL does exactly that:
* https://proxysql.com/documentation/mysql-prepared-statements-pooling-and-caching/
* https://proxysql.com/documentation/multiplexing/
We use proxysql (https://proxysql.com) which works very well. We have not seen any downtime for years. We wrote our own master promotion code a very long time ago; it has proven to be very robust.