Go ahead, self-host Postgres • Hacker News Board

Re: Go ahead, self-host Postgres

#11

Post by ZeroConcerns » Sat, Dec 20, 2025, 4:04 PM UTC

So, yeah, I guess there's much confusion about what a 'managed database' actually is? Because for me, the table stakes are:

-Backups: the provider will push a full generic disaster-recovery backup of my database to an off-provider location at least daily, without the need for a maintenance window

-Optimization: index maintenance and storage optimization are performed automatically and transparently

-Multi-datacenter failover: my database will remain available even if part(s) of my provider are down, with a minimal data loss window (like, 30 seconds, 5 minutes, 15 minutes, depending on SLA and thus plan expenditure)

-Point-in-time backups are performed at an SLA-defined granularity and with a similar retention window, allowing me to access snapshots via a custom DSN, not affecting production access or performance in any way

-Slow-query analysis: notifying me of relevant performance bottlenecks before they bring down production

-Storage analysis: my plan allows for #GB of fast storage, #TB of slow storage: let me know when I'm forecast to run out of either in the next 3 billing cycles or so

Because, well, if anyone provides all of that for a monthly fee, the whole "self-hosting" argument goes out of the window quickly, right? And I say that as someone who absolutely adores self-hosting...

Re: Go ahead, self-host Postgres

#12

Post by WillDaSilva » Sat, Dec 20, 2025, 4:06 PM UTC

ErroneousBosh wrote: post #9

irusensei wrote: post #6

And then there is the urge to Postgres everything. I was disappointed alloy doesn't support timescaledb as a metrics endpoint. Considering switching to telegraf just because I can store the metrics on Postgres.

I've always just Postgressed everything. I used MySQL a bit in the PHP3 days, but eventually moved onto Postgres. SQLite when prototyping, Postgres for production. If you need to power a lawnmower and all you have is a 500bhp Scania V8, you may as well just do it.

It's pretty easy these days to spin up a local Postgres container. Might as well use it for prototyping too, and save yourself the hassle of switching later.

Re: Go ahead, self-host Postgres

#13

Post by isuckatcoding » Sat, Dec 20, 2025, 4:08 PM UTC

Take a look at https://github.com/vitabaks/autobase

In case you want to self host but also have something that takes care of all that extra work for you

Re: Go ahead, self-host Postgres

#14

Post by zbentley » Sat, Dec 20, 2025, 4:09 PM UTC

ipsento606 wrote: post #3

> If your database goes down at 3 AM, you need to fix it. Of all the places I've worked that had the attitude "If this goes down at 3AM, we need to fix it immediately", there was only one where that was actually justifiable from a business perspective. I'm worked at plenty of places that had this attitude despite the fact that overnight traffic was minimal and nothing bad actually happened if a few clients had to wai…

Really? That might be an anecdote sampled from unusually small businesses, then. Between myself and most peers I’ve ever talked to about availability, I heard an overwhelming majority of folks describe systems that really did need to be up 24/7 with high availability, and thus needed fast 24/7 incident response.

That includes big and small businesses, SaaS and non-SaaS, high scale (5M+rps) to tiny scale (100s-10krps), and all sorts of different markets and user bases. Even at the companies that were not staffed or providing a user service over night, overnight outages were immediately noticed because on average, more than one external integration/backfill/migration job was running at any time. Sure, “overnight on call” at small places like that was more “reports are hardcoded to email Bob if they hit an exception, and integration customers either know Bob’s phone number or how to ask their operations contact to call Bob”, but those are still environments where off-hours uptime and fast resolution of incidents was expected.

Between me, my colleagues, and friends/peers whose stories I know, that’s an N of high dozens to low hundreds.

What am I missing?

Re: Go ahead, self-host Postgres

#15

Post by heipei » Sat, Dec 20, 2025, 4:10 PM UTC

I still don't get how folks can hype Postgres with every second post on HN, yet there is no simple batteries-included way to run a HA Postgres cluster with automatic failover like you can do with MongoDB. I'm genuinely curious how people deal with this in production when they're self-hosting.

Re: Go ahead, self-host Postgres

#16

Post by thedougd » Sat, Dec 20, 2025, 4:10 PM UTC

ZeroConcerns wrote: post #11

So, yeah, I guess there's much confusion about what a 'managed database' actually is ? Because for me, the table stakes are: -Backups: the provider will push a full generic disaster-recovery backup of my database to an off-provider location at least daily, without the need for a maintenance window -Optimization: index maintenance and storage optimization are performed automatically and transparently -Multi-datacenter…

It's even worse when you start finding you're staffing specialized skills. You have the Postgres person, and they're not quite busy enough, but nobody else wants to do what they do. But then you have an issue while they're on vacation, and that's a problem. Now I have a critical service but with a bus factor problem. So now I staff two people who are now not very busy at all. One is a bit ambitious and is tired of being bored. So he's decided we need to implement something new in our Postgres to solve a problem we don't really have. Uh oh, it doesn't work so well, the two spend the next six months trying to work out the kinks with mixed success.

Re: Go ahead, self-host Postgres

#17

Post by christophilus » Sat, Dec 20, 2025, 4:12 PM UTC

heipei wrote: post #15

I still don't get how folks can hype Postgres with every second post on HN, yet there is no simple batteries-included way to run a HA Postgres cluster with automatic failover like you can do with MongoDB. I'm genuinely curious how people deal with this in production when they're self-hosting.

I’ve been tempted by MariaDB for this reason. I’d love to hear from anyone who has run both.

Re: Go ahead, self-host Postgres

#18

Post by paulryanrogers » Sat, Dec 20, 2025, 4:12 PM UTC

heipei wrote: post #15

I still don't get how folks can hype Postgres with every second post on HN, yet there is no simple batteries-included way to run a HA Postgres cluster with automatic failover like you can do with MongoDB. I'm genuinely curious how people deal with this in production when they're self-hosting.

RDS provides some HA. HAProxy or PGBouncer can help when self hosting.

Re: Go ahead, self-host Postgres

#19

Post by paulryanrogers » Sat, Dec 20, 2025, 4:13 PM UTC

christophilus wrote: post #17

heipei wrote: post #15

I still don't get how folks can hype Postgres with every second post on HN, yet there is no simple batteries-included way to run a HA Postgres cluster with automatic failover like you can do with MongoDB. I'm genuinely curious how people deal with this in production when they're self-hosting.

I’ve been tempted by MariaDB for this reason. I’d love to hear from anyone who has run both.

IMO Maria has fallen behind MySQL. I wouldn't chose it for anything my income depends on.

(I do use Maria at home for legacy reasons, and have used MySQL and Pg professionally for years.)

Re: Go ahead, self-host Postgres

#20

Post by nhumrich » Sat, Dec 20, 2025, 4:15 PM UTC

What do you postgres self hosters use for performance analysis? Both GCP-SQL and RDS have their performance analysis pieces of the hosted DB and it's incredible. Probably my favorite reason for using them.