Correct me if I'm wrong, but given your profile (I assume someone in the tech world), nothing stopping you from doing all of the above with a local pg. If installing is annoying you could run it in docker.
You're absolutely right, you can use a local pg. This just makes it easier for me, as it's sort of a "sandbox" environment and I can easily take snapshots to do A/B testing or roll things back. I can also send a snapshot to a coworker so they can get my entire environment with all my data in a few seconds.
But now instead of the annoyance of installing pg, you have the annoyance of installing docker. and then writing a dockerfile. And then bootstrapping docker. etc. etc. =)
Who, working with these things regularly, does not have docker installed?
There is already an official image available so you don’t need to write dockerfile yourself. Having an instance up and running is literally just a docker run command away.
Replied to the wrong person, but I'll take that bait anyway: "Ahahahaha, no".
That only works if you live a blissful "all my hosted pg instances use the exact same version" world, which I've never seen be the case for even moderately sized projects. You're going to need multiple Postgres installs if you're going to need pg_dump/pg_restore, which you probably are.
(How you solve that problem, of course, is not a one-size-fits-all, and Docker may be the answer... or it may not)
Doesn’t pg_dump/pg_restore work across versions? (So long as the CLI tools are the latest version). I guess version compatibility could be an issue in theory, but I’m yet to hit into a backwards compatibility issue with Postgres.
I wish. You'd think it'd just be able to check the db to see if there's any schema or procedure incompatibility, but it doesn't. Instead, it goes "Remote uses version X and you're using version Y, sort that out" and then it exits.
Generally use docker myself for this... pg + pgadmin + volume.. spin up when needed, down when not. Works pretty well.. I can see this being useful too though.
