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

231–240 of 407 posts

Re: Go ahead, self-host Postgres

#231

Post by maccard »

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/

Aurora serverless requires provisioned compute - it’s about $40/mo last time I checked.

Re: Go ahead, self-host Postgres

#232

Post by HPsquared »

tjwebbnorfolk wrote: post #226
madeofpalk wrote: post #182

Earlier quoted context omitted.

> but it allows me to say, "we'll have to wait until they've sorted this out, Ikea and Disney are down, too." From my experience your client’s clients don’t care about this when they’re still otherwise up.

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

That's real microeconomics.

Re: Go ahead, self-host Postgres

#233

Post by cobolcomesback »

jread wrote: post #199
Thaxll wrote: post #197

Earlier quoted context omitted.

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/

This was true for RDS serverless v1 which scaled to 0 but is no longer offered. V2 requires a minimum 0.5 ACU hourly commit ($40+ /mo).

V2 scales to zero as of last year.

https://aws.amazon.com/blogs/database/introducing-scaling-to...

It only scales down after a period of inactivity though - it’s not pay-per-request like other serverless offerings. DSQL looks to be more cost effective for small projects if you can deal with the deviations from Postgres.

Re: Go ahead, self-host Postgres

#234

Post by bluepuma77 »

From my point of view the real challenge comes when you want high availability and need to setup a Postgres cluster.

With MongoDB you simply create a replicaset and you are done.

When planing a Postgres cluster, you need to understand replication options, potentially deal with Patroni. Zalandos Docker Spilo image is not really maintained, the way to go seems CloudNativePG, but that requires k8s.

I still don’t understand why there is no easy built-in Postgres cluster solution.

Re: Go ahead, self-host Postgres

#236

Post by RadiozRadioz »

groundzeros2015 wrote: post #230
devin wrote: post #212

What irks me about so many comments in this thread is that they often totally ignore questions of scale, the shape of your workloads, staffing concerns, time constraints, stage of your business, whether you require extensions, etc. There is a whole raft of reasons why you might be a candidate for self-hosting, and a whole raft of reasons why not. This article is deeply reductive, and so are many of the comments.

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

Bad, short-sighted engineers will do that. An engineer who is not acting solely in the best interests of the wider organisation is a bad one. I would not want to work with a colleague who was so detached from reality that they wouldn't consider all GP's suggested facets. Engineering includes soft/business constraints as well as technical ones.

Re: Go ahead, self-host Postgres

#237

Post by rikafurude21 »

roncesvalles wrote: post #213

I'd argue forget about Postgres completely. If you can shell out $90/month, the only database you should use is GCP Spanner (yes, this also means forget about any mega cloud other than GCP unless you're fine paying ingress and egress). And for small projects, SQLite, rqlite, or etcd. My logic is either the project is important enough that data durability matters to you and sees enough scale that loss of data durabili…

You seem insanely miscalibrated. $90 gets you a dedicated server that covers most projects' needs. data durability isnt some magic that only cloud providers can get you.

Re: Go ahead, self-host Postgres

#238

Post by alex23478 »

vovavili wrote: post #161
ninkendo wrote: post #118

Earlier quoted context omitted.

At $WORK we’ve been using the Zalando Postgres kubernetes operator to great success: https://github.com/zalando/postgres-operator As someone who has operated Postgres clusters for over a decade before k8s was even a thing, I fully recommend just using a Postgres operator like this one and moving on. The out of box config is sane, it’s easy to override things, and failover/etc has been working flawlessly for years. It…

For something like a database, what is the added advantage to using Kubernetes as opposed to something simple like Docker Compose?

In this case the advantage are operators for running postgres.

With Docker Compose, the abstraction level you're dealing with is containers, which means in this case you're saying "run the postgres image and mount the given config and the given data directory". When running the service, you need to know how to operate the software within the container.

Kubernetes at its heart is an extensible API Server, which allows so called "operators" to create custom resources and react to them. In the given case, this means that a postgres operator defines for example a PostgresDatabaseCluster resource, and then contains control loops to turn these resources into actual running containers. That way, you don't necessarily need to know how postgres is configured and that it requires a data directory mount. Instead, you create a resource that says "give me a postgres 15 database with two instances for HA fail-over", and the operator then goes to work and manages the underlying containers and volumes.

Essentially operators in kubernetes allow you to manage these services at a much higher level.

Re: Go ahead, self-host Postgres

#239

Post by abrookewood »

franckpachot wrote: post #92
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.

Beyond the hype, the PostgreSQL community is aware of the lack of "batteries-included" HA. This discussion on the idea of a Built-in Raft replication mentions MongoDB as: >> "God Send". Everything just worked. Replication was as reliable as one could imagine. It outlives several hardware incidents without manual intervention. It allowed cluster maintenance (software and hardware upgrades) without application downtime…

"I really dream PostgreSQL will be as reliable as MongoDB" ... someone needs to go and read up on Mongo's history!

Sure, the PostrgreSQL HA story isn't what we all want it to be, but the reliability is exceptional.

Re: Go ahead, self-host Postgres

#240

Post by groundzeros2015 »

RadiozRadioz wrote: post #236
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.

Bad, short-sighted engineers will do that. An engineer who is not acting solely in the best interests of the wider organisation is a bad one. I would not want to work with a colleague who was so detached from reality that they wouldn't consider all GP's suggested facets. Engineering includes soft/business constraints as well as technical ones.

We are saying similar things.
Post reply on HN