Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go ahead, self-host Postgres

pierce.dev

Post reply on HN
Print view View original

401–407 of 407 posts

Re: Go ahead, self-host Postgres

#401

Post by snovv_crash »

strken wrote: post #391
snovv_crash wrote: post #367

Earlier quoted context omitted.

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…

The lede I buried there is whether all of this theater actually gives you better security and availability than 'toy' hardware.

Looking at all the recent AWS, Azure and Cloudflare outages, I posit that it doesn't.

Re: Go ahead, self-host Postgres

#402

Post by balex »

dilyevsky wrote: post #261
arwhatever wrote: post #257

Earlier quoted context omitted.

Me: “Why are we switching from NoNameCMS to Salesforce?” Savvy Manager: “NoNameCMS often won’t take our support calls, but if Salesforce goes down it’s in the WSJ the next day.”

This ignores the case when BigVendor is down for your account and your account only and support is mia, which is not that uncommon ime

JFrog, is that you?

Re: Go ahead, self-host Postgres

#403

Post by lucideer »

bastawhiz wrote: post #368
lucideer wrote: post #332

Earlier quoted context omitted.

> at a company that has reached the scale where employing engineers to manage self-hosted databases is more cost effective than outsourcing. This is the crux of one of the most common fallacies in software engineering decision making today. I've participated in a bunch of architecture / vendor evaluations that concluded managed services are more cost effective almost purely because they underestimated (or even discar…

> Black box debugging is one of the most time costuming engineering pursuits, & even when it's something widely documented & well supported like RDS, it's only really tuned for the lowest common denominator - the complexities of tuning someone else's system at scale can really add up to only marginally less effort than self-hosting (if there's any difference at all). I'm really not sure what you're talking about here…

> Could it be cheaper or faster? Probably

Ultimately, it depends on your stack & your bottlenecks. If you can afford to run slower queries then focusing your efforts elsewhere makes sense for you. We run ~25kqps average & mostly things are fine, but when on-call pages come in query performance is a common culprit. The time we've spent on that hasn't been significantly different to self-hosted persistence backends I've worked with (probably less time spent but far from orders of magnitudes - certainly not worthy of a bullet point in the "pros" column when costing application architectures.

Re: Go ahead, self-host Postgres

#404

Post by bastawhiz »

lucideer wrote: post #403
bastawhiz wrote: post #368

Earlier quoted context omitted.

> Black box debugging is one of the most time costuming engineering pursuits, & even when it's something widely documented & well supported like RDS, it's only really tuned for the lowest common denominator - the complexities of tuning someone else's system at scale can really add up to only marginally less effort than self-hosting (if there's any difference at all). I'm really not sure what you're talking about here…

> Could it be cheaper or faster? Probably Ultimately, it depends on your stack & your bottlenecks. If you can afford to run slower queries then focusing your efforts elsewhere makes sense for you. We run ~25kqps average & mostly things are fine, but when on-call pages come in query performance is a common culprit. The time we've spent on that hasn't been significantly different to self-hosted persistence backends I'v…

> query performance is a common culprit

But that almost certainly has to do with index use and configuration, not whether you're self hosting or not. RDS gives you essentially all of the same Postgres configuration options.

Re: Go ahead, self-host Postgres

#405

Post by [deleted] »

Nextgrid wrote: post #184
satvikpendem wrote: post #119

Earlier quoted context omitted.

If we're talking about CLIs, check out Kamal, the build system that 37signals / Basecamp / DHH developed, specifically to move off the cloud. I think it uses Kubernetes but not positive, it might just be Docker.

It's just Docker - it SSH's in to the target servers and runs `docker` commands as needed.

[deleted]

Re: Go ahead, self-host Postgres

#406

Post by nemothekid »

solatic wrote: post #397
nemothekid wrote: post #388

Earlier quoted context omitted.

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, an…

>Most employees, contractors, and vendors are surprisingly forgiving of one-time screw-ups.

If you are a new business that isn't true. Your comparison to the US federal government is not apt at all - the USG is one of the longest running, stable organizations in the country, people will have plenty of patience for the USG, but they wont have it for your incorporated-last-month business.

Secondly I could make the same argument for AWS. AWS has plenty of downtime - way more than the USG has shutdowns, and there are never been a massive wave of customers off of AWS.

Finally, as a small business, if your payroll gets fucked, your largest assets will use that to walk out the door! The second you miss payroll is the second your employees start seeing the writing on the wall, its very hard to recover moral after that. Imagine being Uber and not paying drivers on time, they will simply drive more often with a competitor.

That said, I still see the parallels with the hypothetical "Accountant forums". The subject matter experts believe their shiny toy is the most critical to the business and the other parts aren't. Replace "US federal government" with "Amazon Web Services", and you will have your "Accountant forums" poster arguing why payroll should be done in house and SLA doesn't matter.

Re: Go ahead, self-host Postgres

#407

Post by j45 »

tempest_ wrote: post #201
j45 wrote: post #198

Earlier quoted context omitted.

Not as often as you might think. Hardware doesn’t fail like it used to. Hardware also monitors itself reasonably well because the hosting providers use it. It’s trivial to run a mirrored containers on two separate proxmox nodes because hosting providers use the same kind of stuff. Offsite backups and replication? Also point and click and trivial with tools like Proxmox. RAID is actually trivial to setup.l if you don’…

> if you don’t compare it to doing it manually yourself Even if you do ZFS makes this pretty trivial as well.

Ah.. ZFS, really under rated and unfortunate with the unrelated history around it, the tech is quite solid.
Post reply on HN