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

341–350 of 407 posts

Re: Go ahead, self-host Postgres

#341

Post by gonzo41 »

Thaxll wrote: post #197
mittermayr wrote: post #116

Self-hosting is more a question of responsibility I'd say. I am running a couple of SaaS products and self-host at much better performance at a fraction of the cost of running this on AWS. It's amazing and it works perfectly fine. For client projects, however, I always try and sell them on paying the AWS fees, simply because it shifts the responsibility of the hardware being "up" to someone else. It does not inherent…

That argument does not hold when there is aws serverless pg available, which cost almost nothing for low traffic and is vastly superior to self hosting regarding observability, security, integration, backup ect... There is no reason to self manage pg for dev / environnement. https://aws.amazon.com/rds/aurora/serverless/

Just use a pg container on a vm, cheap as chips and you can do anything to em.

Re: Go ahead, self-host Postgres

#342

Post by pdimitar »

api wrote: post #250
tjwebbnorfolk wrote: post #226

Earlier quoted context omitted.

Yes but the fact that it's "not their fault" keeps the person from getting fired. Don't underestimate the power of CYA

This is a major reason the cloud commands such a premium. It’s a way to make down time someone else’s problem. The other factor is eliminating the “one guy who knows X” problem in IT. What happens if that person leaves or you have to let them go? But with managed infrastructure there’s a pool of people who know how to write terraform or click buttons and manage it and those are more interchangeable than someone’s DIY…

I never understood the argument of a senior IT person's salary competing for the cloud expenses. In my contracting and consulting career I have done all of programming, monitoring and DevOps many times; the cost of my contract is amortized over multiple activities.

The way you present it makes sense of course. But I have to wonder whether there really are such clear demarcation lines between responsibilities. At least over the course of my career this was very rarely the case.

Re: Go ahead, self-host Postgres

#343

Post by satvikpendem »

sixdonuts wrote: post #310
satvikpendem wrote: post #84

Earlier quoted context omitted.

This would be a strange scenario because why would you keep these people employed? If someone doesn't want to do the job required, including servicing Postgres, then they wouldn't be with me any longer, I'll find someone who does.

No doubt. Reading this thread leads me to believe that almost no one wants to take responsibility for anything anymore, even hiring the right people. Why even hire someone who isn't going to take responsibility for their work and be part of a team? If an org is worried about the "bus factor" they are probably not hiring the right people and/or the org management has poor team building skills.

Exactly, I just don't understand the grandparent's point, why have a "Postgres person" at all? I hire an engineer who should be able to do it all, no wonder there's been a proliferation of full stack engineers over specialized ones.

And especially having worked in startups, I was expected to do many different things, from fixing infrastructure code one day to writing frontend code the next. If you're in a bigger company, maybe it's understandable to be specialized, but especially if you're at a company with only a few people, you must be willing to do the job, whatever it is.

Re: Go ahead, self-host Postgres

#344

Post by yoan9224 »

I've been self-hosting Postgres for production apps for about 6 years now. The "3 AM database emergency" fear is vastly overblown in my experience.

In reality, most database issues are slow queries or connection pool exhaustion - things that happen during business hours when you're actively developing. The actual database process itself just runs. I've had more AWS outages wake me up than Postgres crashes.

The cost savings are real, but the bigger win for me is having complete visibility. When something does go wrong, I can SSH in and see exactly what's happening. With RDS you're often stuck waiting for support while your users are affected.

That said, you do need solid backups and monitoring from day one. pgBackRest and pgBouncer are your friends.

Re: Go ahead, self-host Postgres

#345

Post by arevno »

molf wrote: post #36

> I'd argue self-hosting is the right choice for basically everyone, with the few exceptions at both ends of the extreme: > If you're just starting out in software & want to get something working quickly with vibe coding, it's easier to treat Postgres as just another remote API that you can call from your single deployed app > If you're a really big company and are reaching the scale where you need trained database e…

> trading an hour or two of my time

pacman -S postgresql

initdb -D /pathto/pgroot/data

grok/claude/gpt: "Write a concise Bash script for setting up an automated daily PostgreSQL database backup using pg_dump and cron on a Linux server, with error handling via logging and 7-day retention by deleting older backups."

ctrl+c / ctrl+v

Yeah that definitely took me an hour or two.

Re: Go ahead, self-host Postgres

#346

Post by _ea1k »

I often find it sad how many things that we did, almost without thinking about them, that are considered hard today. Take a stroll through this thread and you will find out that everything from RAID to basic configuration management are ultrahard things that will lead you to having a bus factor of 1.

What went so wrong during the past 25 years?

Re: Go ahead, self-host Postgres

#347

Post by groundzeros2015 »

WackyFighter wrote: post #284
groundzeros2015 wrote: post #230

Earlier quoted context omitted.

Engineers almost never consider any of those questions. And instead deploy the maximally expensive solution their boss will say ok to.

I find it is the opposite way around. I come up with based on open source tooling and I am forced instead to use which is 100% lock in proprietary BS because is partnered and is subsidising development. This has been a near constant throughout my career.

I agree, my statement is too coarse. There can be a lot of organizational pressure to produce complexity and it’s not fair to just blame engineers.

I’ve given a lot of engineers tasks only to find they are “setting up kubernetes cluster so I can setup automated deployments with a dashboard for …”

And similarly in QA I rarely see a cost/benefit consideration for a particular test or automation. Instead it’s we are going to fully automate this and analyze every possible variable.

Re: Go ahead, self-host Postgres

#348

Post by groundzeros2015 »

RadiozRadioz wrote: post #251
groundzeros2015 wrote: post #240

Earlier quoted context omitted.

We are saying similar things.

Ah, you are implying that most engineers are bad, I see. In that case I agree too

I don’t know if they are bad engineers, but they have poor judgment.

Re: Go ahead, self-host Postgres

#349

Post by monus »

tresil wrote: post #24
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.

If you’re running Kubernetes, CloudNativePG seems to be the “batteries included” HA Postgres cluster that’s becoming the standard in this area.

We’ve recently had a disk failure in the primary and CloudNativePG promoted another to be primary but it wasn’t zero downtime. During transition, several queries failed. So something like pgBouncer together with transactional queries (no prepared statements) is still needed which has performance penalty.

Re: Go ahead, self-host Postgres

#350

Post by jrochkind1 »

molf wrote: post #36

> I'd argue self-hosting is the right choice for basically everyone, with the few exceptions at both ends of the extreme: > If you're just starting out in software & want to get something working quickly with vibe coding, it's easier to treat Postgres as just another remote API that you can call from your single deployed app > If you're a really big company and are reaching the scale where you need trained database e…

Agreed. As someone in a very tiny shop, all us devs want to do as little context switching to ops as possible. Not even half a day a month. Our hosted services are in aggregate still way cheaper than hiring another person. (We do not employ an "infrastructure engineer").
Post reply on HN