Live data from Hacker News

Go ahead, self-host Postgres

pierce.dev

391–400 of 407 posts

Re: Go ahead, self-host Postgres

#391
post #273

Earlier quoted context omitted.

Our AWS spend is something like $160/month. Want to come build bare metal database infrastructure for us for $3/day?

At 160/mo you are using so little you might as well host off of a raspberry pi on your desk with a USB3 SSD attached. Maintenance and keeping a hot backup would take a few hours to set up, and you're more flexible too. And if you need to scale, rent a VPS or even dedicated machine from Hetzner. An LLM could set this up for you, it's dead simple.

I'm not going to put customer data on a USB-3 SSD sitting on my desk. Having a small database doesn't mean you can ignore physical security and regulatory compliance, particularly if you've still got reasonable cash flow. Just as one example, some of our regulatory requirements involve immutable storage - how am I supposed to make an SSD that's literally on my desk immutable in any meaningful way? S3 handles this in seconds. Same thing with geographically distributed replicas and backups.

I also disagree that the ongoing maintenance, observability, and testing of a replicated database would take a few hours to set up and then require zero maintenance and never ping me with alerts.

Re: Go ahead, self-host Postgres

#392
post #386

I would suggest if you do host your database yourself consider taking the data seriously. Few easy solutions are using a multi zonal disk [1] with scheduled automatic snapshots [2]. [1] https://docs.cloud.google.com/compute/docs/disks/hd-types/hy... [2] https://docs.cloud.google.com/compute/docs/disks/create-snap...

Scheduled automatic snapshots are not the kind of consistent snapshots you need for a filesystem based backup.

Snapshots might break ACID for last few transactions but it will flush all in-memory writes before taking the freeze. Consider its 1 click solution, its good enough than losing everything?

Re: Go ahead, self-host Postgres

#393
Looking at this list:

    Standard Postgres compiled with some AWS-specific monitoring hooks
    A custom backup system using EBS snapshots
    Automated configuration management via Chef/Puppet/Ansible
    Load balancers and connection pooling (PgBouncer)
    Monitoring integration with CloudWatch
    Automated failover scripting
Every company I've ever on boarded at, that hosted their own database, had number one, and a lot of TODOs around the rest. It's really hard! Honestly, it could be a full time job for a team. And that's more expensive than RDS.

Re: Go ahead, self-host Postgres

#394

Earlier quoted context omitted.

You can self host Supabase too.

Last time I checked, it was a pain in the ass to self-host it

I assume by their own design and also because there are a lot of moving pieces they packaged up together.

Re: Go ahead, self-host Postgres

#395
post #273

Earlier quoted context omitted.

Our AWS spend is something like $160/month. Want to come build bare metal database infrastructure for us for $3/day?

At 160/mo you are using so little you might as well host off of a raspberry pi on your desk with a USB3 SSD attached. Maintenance and keeping a hot backup would take a few hours to set up, and you're more flexible too. And if you need to scale, rent a VPS or even dedicated machine from Hetzner. An LLM could set this up for you, it's dead simple.

[deleted]

Re: Go ahead, self-host Postgres

#396
post #273

Earlier quoted context omitted.

Our AWS spend is something like $160/month. Want to come build bare metal database infrastructure for us for $3/day?

At 160/mo you are using so little you might as well host off of a raspberry pi on your desk with a USB3 SSD attached. Maintenance and keeping a hot backup would take a few hours to set up, and you're more flexible too. And if you need to scale, rent a VPS or even dedicated machine from Hetzner. An LLM could set this up for you, it's dead simple.

Nice troll. But TFA is about corporate IT so hopefully you get whatever.

Re: Go ahead, self-host Postgres

#397

Earlier quoted context omitted.

I'm totally with you on the core vs. context question, but you're missing the nuance here. Postgres's operations is part of the core of the business. It's not a payroll management service where you should comparison shop once the contract comes up for renewal and haggle on price. Once Postgres is the database for your core systems of record, you are not switching away from it . The closest analog is how difficult it…

Ignoring the fact that the assumption that you will automatically have as good or better uptime than a cloud provider, I just feel like you just simply aren't being thoughtful enough with the comparison. Like in what world is payroll not as important as your DBMS - if you can't pay people you don't have a business! If your payroll processor screws up and you can't pay your employees or contractors, that can also affe…

> Like in what world is payroll not as important as your DBMS - if you can't pay people you don't have a business!

Most employees, contractors, and vendors are surprisingly forgiving of one-time screw-ups. Hell, even the employees who are most likely to care the most about a safe, reliable paycheck - those who work for the US federal government - weren't paid during the recent shutdown, and not for the first time, and still there wasn't some massive wave of resignations across the civil service. If your payroll processor screws up that badly, you fire them and switch processors.

If your DBMS isn't working, your SaaS isn't working. Your SLA starts getting fucked and your largest customers are using that SLA as reason to stop payments. Your revenue is fucked.

Don't get me wrong, having working payroll is pretty important. But it's not actually critical the way the DBMS is, and if it was, then yeah you'd see more companies run it in-house.

Re: Go ahead, self-host Postgres

#398
post #358
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.

This is my gripe with Postgres as well. Every time I see comments extolling the greatness of Postgres, I can't help but think "ah, that's a user, not a system administrator" and I think that's a completely fair judgement. Postgres is pretty great if you don't have to take care of it.

I manage Postgresql and the thing I really love about it is that there's not much no manage. It just works. Even setting up streaming replication is really easy.

Re: Go ahead, self-host Postgres

#399
post #265

Earlier quoted context omitted.

Yo I'm curious if you have any pointers on how you went about this to share? Did you use their provided upgrade script or did you instrument the upgrade yourself "out of band"? rsync? Currently scratching my head on what the appropriate upgrade procedure is for a non-k8s/operator spilo/patroni cluster for minimal downtime and risk. The script doesn't seem to work for this setup, erroring on mismatching PG_VERSION whe…

I did not use a script (my environment is bare metal running ubuntu 24). I read these and then wrote my own scripts that were tailored to my environment. https://pganalyze.com/blog/5mins-postgres-zero-downtime-upgr... https://www.pgedge.com/blog/always-online-or-bust-zero-downt... https://knock.app/blog/zero-downtime-postgres-upgrades Basically - Created a new cluster on new machines - Started logically replicating -…

Thank you! o7

Going to have some more figuring out what's up with spilo - turns out that running that outside of k8s is rare and not much documented. But it's still patroni so this is very helpful.

Re: Go ahead, self-host Postgres

#400
post #358

Earlier quoted context omitted.

This is my gripe with Postgres as well. Every time I see comments extolling the greatness of Postgres, I can't help but think "ah, that's a user, not a system administrator" and I think that's a completely fair judgement. Postgres is pretty great if you don't have to take care of it.

I manage Postgresql and the thing I really love about it is that there's not much no manage. It just works. Even setting up streaming replication is really easy.

Initial setup is rarely the hard part of any technology.
Post reply on HN