I'm thinking of using Postgres for a project, but a DBA friend told me operationally it's more challenging than MySQL. Unfortunately, he can't elaborate. Does anyone have real work experience? Or is it based on outdated "PG must manually vacuum frequently"?
back
9 comments
Postgres has some disadvantages that can pop up on certain workloads (eg. bloat) but so does MySQL. And most of those limitations are only when you've got long open transactions, trying to hammer it IO wise, or you're making really big databases (100GB-1TB or more). However for both Postgres and MySQL there is plenty of documentation about these problems, and how to resolve them. So you'll never be "stuck" with issues.
In general I find postgres "just works" a lot more than MySQL. MySQL has a really bad habit of sticking with bad defaults for a long period, while having better configuration available. On the other hand postgres devs actively remove/change defaults so you're always getting the best it has to offer.
If you pick one, and you don't like it there are plenty of tools to change between them. If you're curious you could even deploy both of them.
One thing is that Postgres doesn’t let you just upgrade to a new major version, as it doesn’t update the format of the on-disk binary database files; you must replicate from an existing node or dump/restore. MySQL upgrades the previous version when a new version is installed (which can cause problems, but is certainly “easier”).
Pg_upgrade [0] is an official part of postgres and does the binary inplace upgrade for you. You should obviously test before running in production, but it has worked perfectly for us when upgrading a 10+TB cluster from pg11 to pg13
Not totally ideal if you're using containers as it requires the binaries of the old and new version, unless I'm missing something.
That's hardly a PostgreSQL issue. If your container tech does not allow installing both old and new version of the binaries, it's a silly container tech.
Well I use the official Postgresql docker image ;)
Also it looks like this is not new https://github.com/docker-library/postgres/issues/37
Note that the "official" PostgreSQL docker image is maintained by Docker Inc - not by PostgreSQL contributors/members.
Containerized DBs are great for dev work, toy projects, etc.
Notsomuch for production. I know... folks do it. But I wouldn't run anything on it that I wouldn't do w/ sqlite.
Why not? Having the whole application in one Kubernetes setup, with all databases and other services is very convenient. Are you talking about performance overhead, or are there other drawbacks to this approach?
It does not make sense to run a rdbms in a container in prod; the entire OS is your container.
It makes sense for me using CapRover for my side projects (with multiple envs) all in one cheap server.
All distros I've ever used (debian, arch) provide previous and current version of postgresql for the purpose of easy pg_upgrade.
Debian even has special custom helper scripts for doing it. So just build your container with both postgres versions?
I think this is very convenient; you don't want to automatically upgrade a big database because you probably want to choose the downtime window. This is obviously by design, but I'd also like being able to automate the pg_upgradecluster pg_dropcluster process, specially for install-and-forget little databases.
IMO, the biggest shock from the MSSQL/MYSQL to PostgreSQL migration was not having 1 or 2 specific files per database, specially if you used to backup the files instead of doing a formal database backup.
Are you going to operate it our just rent out some cloud service?
Postgres by itself doesn't have a great horitzontal scaling strategy as of now I think. You need Citus or somt like that on top, maybe your friend was referencing that?
You can fiddle with the autovacuum daemon[1,2] but we've never really had to. These days we just run AWS RDS when it counts or a dedicated VPS when it doesn't and things go fine--
[1,2] https://www.postgresql.org/docs/13/routine-vacuuming.html https://www.postgresql.org/docs/current/planner-stats.html
The main issue we get is the 1 connection = 1 process issue although there are ways to mitigate that (namely pgbouncer).
I don’t know if there are distros which tune it, but the default configuration is usually… conservative.
I wouldn't imagine postgres is really much harder than MySQL.
Both are a degree more difficult than NoSQL. The main issue is maintaining schema's
perhaps your DBA friend was operating PG themselves?
nowadays postgres in the cloud does all of this for you.
MySQL is for that aren't really DBAs and don't want to be (this doesn't mean DBAs don't use it). It's a lot easier to manage.
Your DBA friend is stuck in 2000's. Let dinosaurs die and you go with PGSQL because is superior to MySQL on everything.
And don't take my word for it, see for yourself here:
https://en.wikipedia.org/wiki/Comparison_of_relational_datab...
And MySQL is an Oracle product these days, go with MariaDB instead as this one is a MySQL fork made by the original papa of MySQL.
Lacks first class temporal tables. Maybe not important to you and not on that list so do we dismiss that.