zlacker

[return to "No More Hidden Changes: How MySQL 9.6 Transforms Foreign Key Management"]
1. direwo+mZd[view] [source] 2026-02-04 21:48:31
>>ksec+(OP)
yeah but it's Oracle. You want MariaDB now.
◧◩
2. Hacker+i7e[view] [source] 2026-02-04 22:28:29
>>direwo+mZd
I prefer PostgreSQL. Don't see any advantage of MySQL/Maria.
◧◩◪
3. evanel+Cje[view] [source] 2026-02-04 23:40:30
>>Hacker+i7e
A few major areas where MySQL/MariaDB excels:

Threaded connection model (no process spawning)

Undo-based MVCC (no need for vacuum)

InnoDB's use of a clustered index for PK (has pros/cons, but better for some workloads)

Ability to use alternative storage engines such as MyRocks (LSM based instead of B-tree; best-in-class compression)

Support for index hints (so query plans won't randomly change and bring your site down)

More mature logical replication (fully supports DDL, has no concept of limited "replication slots", etc)

That all said, there are also many areas where Postgres is better! Like all things in computer science, there are architectural trade-offs, and no single silver bullet is the best choice for all workloads.

◧◩◪◨
4. waynes+2oe[view] [source] 2026-02-05 00:10:24
>>evanel+Cje
Your list confirms that MySQL is irrelevant to me.
◧◩◪◨⬒
5. direwo+tpe[view] [source] 2026-02-05 00:20:01
>>waynes+2oe
Why act so snobbish about it? They're both cromulent databases. You should try doing one project with each. The converse of this list would tell the diehard postgres user that mariadb is irrelevant to him.

They have quite different internal design, this affects what features are possible. No clustered index in postgres for instance, and UPDATE can reorder rows, but it supports replication much better.

[go to top]