Hacker News Reader

Comment by gmac | Hacker News Reader

Postgres. Fast, full-featured, rock-solid, and a great community.

I think many of us can’t be bothered to go over (again) the issues we’ve had with MySQL in the past. The last straw for me was about ten years ago, when I caught MySQL merrily making up nonsense results for a query I’d issued that accidentally didn’t make any sense.

Very likely this particular issue, and others like it, have been fixed in the meantime. But I just got the sense that MySQL was developed by people who didn’t quite know what they were doing, and that people who really did know what they were doing weren’t ever likely to be attracted to that to fix it.

View on HN

FWIW, it hasn't changed in ten years.

Here is an 18-year-old bug, that DELETE triggers don't work for foreign key cascades: https://bugs.mysql.com/bug.php?id=11472

That makes the entire feature mostly worthless. Reported in 2005, last updated in 2008.

---

While I would choose PostgreSQL every time, MySQL has the following advantages:

1. Write-performance, due to fundamental design tradeoffs. [1]

2. Per-connection resources, due to single-process design.

3. Related to #1, no vacuum requirement.

[1] https://www.uber.com/blog/postgres-to-mysql-migration/

Good you shouldn't be using them. You shouldn't be using foreign keys either. It just makes working with data harder and doesn't help with constraining it if your data modifications are inside transactions and properly written statements.

Having used postgres for the past decade, I tried MySQL for a side project to see whats changed with it. The sad answer is that it feels like nothing has changed - Oracle seems to have let what used to be a core technology of the industry languish.

I'm sure there are use cases where MySQL will be the better choice over postgres, but the future for the stack looks bleak.

i think one is also referring to mariadb here and not just mysql. Maybe that's better enough? I wouldn't know, I just go with postres.

Creating a series of connections very quickly is cheaper in MySQL and MariaDB than in PostgreSQL. Typically, a connection poller is used before PostgreSQL to support connection scalability.

I'm not sure if there has been a recent breakthrough that has changed that. I think that still applies today. Correct me if I'm wrong.

You can create a series of connections in postgres just as fast. The connection pooler you are referring to is when you put pgBounce or pgPool in between your pgdb and your client software to expand beyond the physical limits of connections and optimize clustered architectures. MySQL at scale is replication only. A few commercial offerings for MySQL like planetscale have brought MySQL into the 21st century. Postgres has a couple ways of clustering, sharding, scaling, beyond your Wordpress database.

    Oracle seems to have let what used to be a core 
    technology of the industry languish

I think slowly squeezing the life from MySQL was a very explicit goal for them. After the big wins (Wal-Mart, etc) MySQL had 15-20 years ago I think it was very clear MySQL was going to chip away at more and more of Oracle's business.

I wonder how much Oracle spends on MySQL every year? They're spending a lot of money to keep MySQL at kind of a "not quite good enough" state. But they can't kill it outright - it'd be like boiling a frog fast instead of slow.

In the end, I wonder what extinguishing MySQL really accomplished for them. It might have bought them some breathing room but Postgres quickly filled MySQL's old segment.

You are looking for long term planning where there is none. The only relevant question for those in charge of the project is: “How do I make my quarterly report to investors look slightly better than last quarter’s?”

Strange take when FB, twitter, Square and new startups such as Faire(#4 valued private YC co) are all using MySQL to some/large degree. Stripe uses MySQL too in combination with other DBs including Postgres.

You're not considering the timeline of events.

I'm unfamiliar with Faire but the rest were already using MySQL at the time of Oracle's acquisition in 2010. Switching backends would have been rough for those companies and this was... 2010, meaning Postgres was not nearly as performant or full featured as it is today. As mentioned in other comments, FB's investment in customizing MySQL has been extensive. They've poured a lot into their own fork of it.

More to the point, look at MySQL's progress since 2010. Do you think it has been largely stifled since then, or do you think it has kept pace with Postgres? It's been largely stagnant.

I'd love to hear your alternative theory, of course. You think Oracle bought MySQL to... what, exactly? Make it amazing?

Imo mysql is decent enough for many years, and PG has relatively major outstanding architecture problem (see my Other comment in this thread)

I don’t think either DB is bad, but the whole MySQL is dead and needs serious work idea doesn’t make sense to me. What problem does MySQL still have that needs fixing in your opinion?

(Full disclosure, I work for Oracle)

Anyone who says no investment has been into MySQL I suspect never took the time to read the features/release notes for MySQL 8

https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html

Didn't 8 ship 5 years ago?

Their release model changed with MySQL 8 -- they do rolling point releases every quarter with new features sprinkled in as they're ready. Quite a few new major features have been released that way, including INSTANT alters, parallel index builds, CLONE plugin, major changes to how UNDO logs are sized... it's more like Windows 10's release model.

Very recently they've mentioned they'll be changing this again to have separate LTS releases, which is a positive change stability-wise.

Really wish they bump up the version number or something. It makes discussions with MySQL a lot easier.

Well, you got me there. It stagnated for so long relative to others that I didn't realize the pace had picked up in a big way.

Facebook maintains a patch-set, not a full fork. They still track Oracle's releases and apply their patches on top.

Facebook definitely has the resources to migrate to Postgres, if there was any motivating reason to do so. Indeed, Facebook developed their own LSM-based key-value store (RocksDB) and MySQL storage engine based on it (MyRocks) and then migrated the majority of their db fleet to that. In total that's massively more work than migrating to Postgres would have been.

Part of the reason was that MyRocks provides better compression than pretty much any other possible choice, and that adds up to an astronomical amount of cost savings at Facebook's scale. In contrast, what would Facebook have gained from moving to Postgres instead?

It took me until here to realise we were talking about MySQL, not SQLite, because honestly 'in 2023' isn't that the comparison, pg vs sqlite?

> I'm sure there are use cases where MySQL will be the better choice over postgres, but the future for the stack looks bleak.

see, I'm pretty sure there basically weren't. It lucked out at the right moment in the late 1990s. Also, Slashdot used it.

The only use case I can think of is when you want an application, and it requires or is highly optimised to MySQL. Otherwise, it should actively be avoided.

Actually I would argue that there isn’t a single reason to use MySQL over Postgres (barring the obvious- it’s what the team already knows, or the company already uses, etc.)

Yep. The real question here is: it's 2023, why would you choose MySQL over PostgreSQL?

Not that there aren't reasons. There are some. But for starting out with a new app without a very, very good reason to do something different? PostgreSQL every day of the week.

Ease of updates is a very good reason. Handling connections too.

Working with MySQL (MariaDB, but doesn't make much difference). Never get any issues that couldn't be explained by architectural or development mistakes.

Just as example - how do you create read-only user (SELECT only) in Postgres? In MySQL it's extremely simple and it works, while in Postgres it's a nightmare to create and maintain

> Just as example - how do you create read-only user (SELECT only) in Postgres? In MySQL it's extremely simple and it works, while in Postgres it's a nightmare to create

Isn’t that

  GRANT SELECT ON ALL TABLES IN SCHEMA foo TO bar;

> and maintain

If you mean you want to grant a user select rights to whatever table gets created in the future (a somewhat questionable idea from a security viewpoint):

  ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT SELECT ON TABLES TO bar;

I think both are possible in PostgreSQL 9 and later (https://www.postgresql.org/docs/9.0/sql-grant.html , https://www.postgresql.org/docs/9.0/sql-alterdefaultprivileg...)

That version is from 2010.

I guess the lesson is that both these systems evolve fairly rapidly. You can’t use quirks you remember from over 5 years ago to judge their current versions.

It is correct but apparently not sufficient - you need to give CONNECT access to user profile.

It’s really unfair because a lot may have changed in 10 years so it might be worth reconsidering.

But I’m like you, MySQL did some nonsense once that took me hours to work out. So now I really can’t be bothered with any potential quirks it may still have. This is not an SNL sketch.

Reply on news.ycombinator.com