Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

231–240 of 366 posts

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

#231

Post by tmountain »

12907835202 wrote: post #111
test6554 wrote: post #58

I've been using MariaDB (MySQL) as a hobbyist for years. I just set up a couple myqsql servers with phpmyadmin on Raspberry PIs and use them for local development. Basic crud apps, etc. I've always assumed that PostgreSQL is a step up, but never really bothered to look into what I get for the effort. Do I really get anything if I'm not trying to make apps at scale?

Same position. There's so many things I want to learn I'm not sure postgres is such a step up from MySQL that it's worth being at the top of the list.

If you’re not at the level of detail to care about transaction isolation levels, clustered indexes, and the implementation details of replication, you can invest your time elsewhere. For certain use cases and workloads, the differences can matter a lot, but many developers are just looking for a backing store for their CRUD app and in that case, either is likely fine.

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

#232

Post by arp242 »

bkuehl wrote: post #203

A lot of comments for Postgres, but it's the only major DB in 2023 that does not let you choose your character collation when creating a database. That is pretty much a deal breaker day 1. Guess you'll be doing a tolower() on every db search and not use indices which will kill performance or using column collation casts on every search query. I just don't get it. I once tried to migrate a SQL Server DB to Postgres an…

> doing a tolower() on every db search and not use indices

If you create the index with lower() it will uses that; e.g. "create index on tbl (lower(email))" and then "select * from tbl where lower(email)=lower($1)". That's more or less the standard way to do this but there are some other ways as well. It's more explicit than MySQL, so in that way it's better. It's more effort and easy to forget, and in that way it's worse – either way: it's definitely possible to do case-insensitive searches with indexes.

When I first used PostgreSQL I ran in to "how the hell do I do this?! MySQL just lets me [...]" kind of issues, but after many years of PostgreSQL usage I now have the opposite when I use MariaDB, which also has its share of awkwardness and issues (just different ones).

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

#234

Post by [deleted] »

jjeaff wrote: post #227
EamonnMR wrote: post #150

Earlier quoted context omitted.

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.

I have not had that happen in MySQL either, at least, not with innodb. what command would that be? I do remember getting bad tables with myisam tables a decade ago, sometimes after a bad shutdown.

[deleted]

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

#235

Post by throw0101b »

dijit wrote: post #36

There is almost no good reason to choose MySQL over PostgreSQL for any operational reason, I did a deep dive many moons ago (before major improvements in performance to postgres) and people were saying that MySQL was faster. I found that not to be true and the differences have only gained even more favour towards postgres. also, I assume you mean MariaDB as MySQL is owned by Oracle and I would greatly implore anyone…

> There is almost no good reason to choose MySQL over PostgreSQL for any operational reason

Galera is the main one I can think of:

* https://galeracluster.com/library/documentation/tech-desc-in...

* https://mariadb.com/kb/en/what-is-mariadb-galera-cluster/

* https://packages.debian.org/search?keywords=galera

I'm not aware of any multi-master, active-active(-active) replication system that is open source for PostgreSQL.

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

#236

Post by solarkraft »

Doctor_Fegg wrote: post #13

For anything involving location, choose Postgres because PostGIS is just so good.

PostGIS is somewhat of a standard interface for geolocation data and one of the main interfaces of QGis, the other being based on SQLite. It's kind of cool how powerful it is, being a "real" database instead of some more contrived format.

My adventures with QGis+PostGIS have also led me to discover the fun fact that even setting the TLS mode to "enforce" may enforce that you're using TLS ... but not that the certificates are correct. Silly. It also won't use the system's store when set to "full". Oh well.

By the way: I find Railway to be a great home for low-use Postgres/PostGIS databases. You basically pay for operations and the free tier is totally fine for semi-casual use (about 1-2k entities) with a few people from across the pond.

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

#237

Post by JohnBooty »

srcreigh wrote: post #221
JohnBooty wrote: post #146

Earlier quoted context omitted.

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…

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?

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

#238

Post by bkuehl »

arp242 wrote: post #232
bkuehl wrote: post #203

A lot of comments for Postgres, but it's the only major DB in 2023 that does not let you choose your character collation when creating a database. That is pretty much a deal breaker day 1. Guess you'll be doing a tolower() on every db search and not use indices which will kill performance or using column collation casts on every search query. I just don't get it. I once tried to migrate a SQL Server DB to Postgres an…

> doing a tolower() on every db search and not use indices If you create the index with lower() it will uses that; e.g. "create index on tbl (lower(email))" and then "select * from tbl where lower(email)=lower($1)". That's more or less the standard way to do this but there are some other ways as well. It's more explicit than MySQL, so in that way it's better. It's more effort and easy to forget, and in that way it's…

I was disappointed with MariaDB and tried it before using MySQL. It is so far behind MySQL that it can't be considered equivalent anymore. And I really wanted to use MariaDB instead.

The "MySQL just lets me" stuff eventually adds up and hinders development. For example, your lower() on the param example is now incompatible with most ORMs unless you do that in code or create a special SQL statement for that. This isn't all fringe cases that you run into when you're months in either. I really wonder on some of these comments saying they've vetter both and Postgres wins hands down.

Postgres is solid but it definitely has its warts and downsides too.

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

#240

Post by [deleted] »

endgame wrote: post #116

https://web.archive.org/web/20211206040804/https://blog.sess... From a former MySQL developer: > let me point out something that I've been saying both internally and externally for the last five years (although never on a stage—which explains why I've been staying away from stages talking about MySQL): MySQL is a pretty poor database, and you should strongly consider using Postgres instead.

[deleted]
Post reply on HN