I wouldn't say that postgres is hard to tune. Yes it has ~300 parameters in a config file, but a lot of those are to do with logging/admin etc.

There are about 6 parameters that I might touch on every deployment:

Listen address, shared buffers (default it to 25% RAM), connection counts, max workers (CPU core count), max parallel workers and max WAL keep segments.

That's 95% of the tuning you need on an average deployment. The rest is a bit dependent on workload (like checkpoint timeouts on heavy-write boxes).

EDIT: And when I say "need", the actual defaults out of the box will usually get you a long way. Just set the right listen address and let it do its thing.

Thanks. Without a lot of time invested it's hard to figure this out on your own, I appreciate this summary.

The comments here have bolstered my resolve to move to Postgres. :)

Not really. In nearly every case, the "Postgres is too hard" complaints are really just "Postgres doesn't work exactly like MySQL" complaints.

The area MySQL people get hung up on, generally, is the security model in pg_hba.conf. But this is a seriously powerful feature, and not at all hard to configure once you grasp what's going on.

I appreciate the note about complaints. I try to filter these kinds of things out (like amazon reviews that say "it's not what I thought it was so I rate a zero").

I will look into the security conf the next time I try it out. Thanks!

I never made any changes to Postgres for development and it was blazing fast. I made few simple changes for production to let it use more memory (just few lines that you'll find in any guide) and that was about it. I guess, there are plenty of handles for very pro users when they need to squeeze last few percents of performance, but generally it just works fast.

This site is actually misleading in my opinion; someone with no prior exposure might think postgresql users are obligated to spend their time in endless configuration push ups. That is definitely not the case. As the parent points out, developers rarely have to change more than a few things. Production means real loads and real loads drive administrators to configure and tune, but that's as true for MySQL/MariaDB as it is for Postgresql.

Over here[1] you can read about the 1163 snake cased MariaDB variables if you want... 231 of them are specific to innodb alone.

[1] https://mariadb.com/kb/en/server-system-variables/

Thanks, that is what I was hoping for.

no need to be concerned really. i have used mysql a while ago before switching to postgres and the stories are the same on both sides :) i think you will hear that only the "enterprise" dbs users supposedly have it nice...

Are you saying that enterprise people prefer Postgres?

no that the saying goes that management tools (oracle, mssql, etc...) for enterprise db are better

Ah, so you are implying that Postgres (being opensource and not enterprise) has less comprehensive tools?

My experience is that open source software is almost always managed through config files... Is this your point?