MySQL is equally easy to get running, and has FAR less maintenance overhead. It also scales better on its own, due to a threaded connection model vs. Postgres’ process model. The main trade-off is less extensibility, but IME Postgres’ more esoteric types are rarely used anyway.
The other tradeoff (perhaps larger, actually) is poor performance if using a non-k-sortable PK, like a UUIDv4. Unfortunately this is extremely common.
Golang is great but depending on the job market in a given country, might be a little bit esoteric.
If you were aiming for one of the more popular options that still scale pretty well, you might pair either PosgreSQL/MariaDB/MySQL with one of the JVM languages (e.g. Java) or one of the CLR languages (e.g. C#). Both runtimes and their languages are okay and have pretty big ecosystems.
Then again, Node or even PHP might be enough for most apps, maybe even Python or Ruby with a bit of vertical (and simple horizontal) scaling down the line.
Just be prepared for that monolith to grow into an eldritch nightmare of dependencies somewhere between 5 to 15 years later. Currently working on such a Java system, it makes the laptop thermal throttle regularly.
The process thing is irrelevant if you're using a decent database library with connection pooling. Mysql also performs/scales better when keeping connection count proportional to the hardware. I'm personally not a fan of golang (scala has similar performance while being much easier to maintain IMO), but at least pooling is normal/relatively transparent there.
As with using many connections, a UUIDv4 PK is a case of "don't do that".
I’d say greatly reduced in magnitude, but not irrelevant. I’d also prefer to use middleware like PgBouncer or PgCat rather than relying on a library’s connection pooler, mostly because the latter IME has a habit of causing fun surprises from people not properly handling transactions.
> “don’t do that”
If I could get people to use RDBMS properly, I’d be both thrilled and potentially out of a job.
