Hacker News Reader

Comment by kiernanmcgowan | Hacker News Reader

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.

View on HN

    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?

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.

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?

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.)

> 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.

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.

Reply on news.ycombinator.com