Live data from Hacker News

Ask HN: It's 2023, how do you choose between MySQL and Postgres?

news.ycombinator.com

291–300 of 366 posts

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#291

What is go-to solution for Postgres to have data encrypted on disk? I think that MySQL is more popular in enterprise as there's transparent encryption in enterprise version that's single click.

Encrypt at the block level, e.g. LUKS or at the filesystem level: ZFS.

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#292
post #229
post #160

Earlier quoted context omitted.

I forget if there's an equivalent for the first one, but from psql there is a translation of mysql's "DESC table" as "\d table", and the rest are: \dt \l SELECT * FROM pg_stat_activity;

> I forget if there's an equivalent for the first one Not really; PostgreSQL doesn't store the original query, so you'll need to re-create it from pg_class, pg_attribute, and all of that (which is really what \d and such in psql do). The easiest way is probably pg_dump, but it's best to just get used to \-commands because it's really just the same thing.

There is an extension that does that: pgddl. [1]

[1]: https://github.com/lacanoid/pgddl

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#293
post #276

Earlier quoted context omitted.

I mean, for most mature ecosystems / technology stacks I think the “no one size fits all, just strategic design trade-offs” theory largely holds true as an objectively accurate account of the “choosing the best tool“ situation …. but IMO, I think it’s worth noting that occasionally, some rare unique and functionally superlative technology comes along that in practice transcends every alternative from the onset and in…

> something maybe like Git, most immediately comes to mind, as an example of the de-facto standard for distributed VCS basically since … 1995 when Linus decided to create it? hot take. might be the most popular, maybe even by a large margin, but I think you'll find a good chunk of people who have actually tried different VCSs don't think it's the best.

Yah, I think that’s probably true. But that’s also hard to reconcile with the reality of the adoption trending consistently away from any alternative and only towards Git. And “large margins” are indeed pretty objectively the case (from the largest developer surveys the breakdown 10 years ago was like 70% Git to everything, growing to ~95% in 2022). Usually the phenomenon you’re describing, leads to other alternatives becoming more popular not less (even if the most popular standard continues to eclipse the field. Here is would seem these highly likable alternatives for those who took the plunge are nevertheless dwindling into irrelevance…

I suspect the die-hard proponents of Mercurial, or SVN, or whatever else, these few pagan heretics that might exist out there wherever they’re hiding, have found themselves in a camp different to the Git standard likely on the basis of electing to be intentionally contrarian / anti-normative as the general catalyst, and rather not, as a function of struggling with Git to the point of being so disillusioned they call it quits and head out looking for greener pastures. I think in practice the most common result of encountering problems with Git is, fix the problems. And functionally I think that’s resulted only in furthering it’s supremacy over alternatives, despite there existing a handful of cultish weirdos who are _really_ into Mercurial and prefer not to fux with Git as a personal lifestyle choice haha)

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#294
post #109

Unpopular opinion on HN apparently, but MySQL - It's less featureful, and I'd consider that a strong virtue in the YAGNI camp - less to go wrong, less mental overhead. - Maintenance is simpler and far less necessary in my general experience. - Replication is simpler and more reliable. - You can tell the query optimizer what to do. When this is needed, you'll be thankful. It's a godsend. That said, I wouldn't run Orac…

> It's less featureful, and I'd consider that a strong virtue in the YAGNI camp - less to go wrong, less mental overhead.

Imagine when you actually need any of the features that PostgreSQL provides like pub/sub, logical replication, JSONB etc. With MySQL you might have to hack a solution that is much more complex or you have to set up an entirely separate tool. What I find nice with PostgreSQL is that for simple cases you can get away without a dedicated key/value store or a queue or a full text search engine. You can do a lot of these kinds of tasks with just a single database.

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#295
post #294
post #109

Unpopular opinion on HN apparently, but MySQL - It's less featureful, and I'd consider that a strong virtue in the YAGNI camp - less to go wrong, less mental overhead. - Maintenance is simpler and far less necessary in my general experience. - Replication is simpler and more reliable. - You can tell the query optimizer what to do. When this is needed, you'll be thankful. It's a godsend. That said, I wouldn't run Orac…

> It's less featureful, and I'd consider that a strong virtue in the YAGNI camp - less to go wrong, less mental overhead. Imagine when you actually need any of the features that PostgreSQL provides like pub/sub, logical replication, JSONB etc. With MySQL you might have to hack a solution that is much more complex or you have to set up an entirely separate tool. What I find nice with PostgreSQL is that for simple case…

Correct, but as far as I know MySQL has those mentioned features but the overall management effort seems to be considerably lower.

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#296
At our company, we provide Postgres 24x7 support. We have partners that provide support for other databases, and for some projects we work together with companies that have multiple databases.

We have over the years compared the rate of production incidents Postgres vs MySQL. It's roughly 1:10 (MySQL has around 10 times more production incidents than Postgres).

You may consider this anecdotal evidence, but numbers managed here are quite significant.

The gist is that Postgres is not perfect nor free from required maintenance and occasional production incidents. But for the most part, it does the job. MySQL too, but with (at least from an operational perspective) many more nuances.

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#297

piggybacking on this: does anyone know a Postgres alternative to PlanetScale?

CockroachDB is PostgreSQL compatible and is distributed SQL supporting single-region, multi-region and multi-cloud deployments.

It's PostgreSQL protocol compatible, it's not PostgreSQL compatible. There are many differences. For more compatibility, check out YugabyteDB.

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#299
It depends on my requirements and context, really. THESE DAYS with docker, postgres is almost a no-brainer for basically anything that _I_ do, anyway. If I even need a heavy write load or external-access-via-network then PG, otherwise for my mostly simple CRUD needs SQLITE, quite honestly.

I have a production app on MySql, but that was before docker and MySQL was a fair bit easier to setup then. That was my need at the time.

Re: Ask HN: It's 2023, how do you choose between MySQL and Postgres?

#300
post #109

Unpopular opinion on HN apparently, but MySQL - It's less featureful, and I'd consider that a strong virtue in the YAGNI camp - less to go wrong, less mental overhead. - Maintenance is simpler and far less necessary in my general experience. - Replication is simpler and more reliable. - You can tell the query optimizer what to do. When this is needed, you'll be thankful. It's a godsend. That said, I wouldn't run Orac…

I would disagree on maintenance being simpler. I have never had Postgres randomly munge a table and require me to run a command to fix it.

My needs are meager (simple CRUD, low volume), but I haven't had that happen in MySQL either, in over 15 years of running it in production.

Not saying it can't happen, but I don't think it's a common occurrence.

Post reply on HN