Live data from Hacker News

Why we moved from AWS RDS to Postgres in Kubernetes

nhost.io

41–50 of 153 posts

Re: Why we moved from AWS RDS to Postgres in Kubernetes

#41
post #23

Ah, the 'ol sunk cost fallacy of infrastructure. We are already investing in supporting K8s, so let's throw the databases in there too. Couldn't possibly be that much work. Sure, a decade-old dedicated team at a billion-dollar multinational corporation has honed a solution designed to support hundreds of thousands of customers with high availability, and we could pay a little bit extra money to spin up a new database…

Quoted post unavailable.

> I bet you also hate on people making their own espresso instead of just going to starbucks

Hobbies are not the same as bottom line business.

As with everything, managing state at scale is _very_ hard. Then you have to worry about backing it up.

Re: Why we moved from AWS RDS to Postgres in Kubernetes

#42
post #23

Ah, the 'ol sunk cost fallacy of infrastructure. We are already investing in supporting K8s, so let's throw the databases in there too. Couldn't possibly be that much work. Sure, a decade-old dedicated team at a billion-dollar multinational corporation has honed a solution designed to support hundreds of thousands of customers with high availability, and we could pay a little bit extra money to spin up a new database…

Quoted post unavailable.

[deleted]

Re: Why we moved from AWS RDS to Postgres in Kubernetes

#43
post #4

Having recently heard a lot of about PostgreSQL in Kubernetes (cloudNativePG for example) it always makes me wonder about the actual load and the complexity of the cluster in the question. > This is the reason why we were able to easily cope with 2M+ requests in less than 24h when Midnight Society launched This gives the answer, while it's probably not evenly distributed gives 23 req/sec (guess peak 60 - 100 might be…

> This is the reason why we were able to easily cope with 2M+ requests in less than 24h

I thought this was referring to 2M+ requests per second over a ramp period of 24h, not 2M requests per 24h?

Re: Why we moved from AWS RDS to Postgres in Kubernetes

#45
post #26

Earlier quoted context omitted.

AWS RDS is 10x slower than BareMetal MySQL (both reads and writes). Slowness is mainly due to the reason that Storage is over network for RDS. Not bad to invest some extra time to get better performance. You are falling to “Appeal to antiquity” fallacy if you think something old is better.

It's unlikely running it on K8S (which is itself going to run on underpowered VMs with networked storage) is going to help. If you're gonna spend effort in running Postgres manually, do it on bare-metal and at least get some reward out of it (performance and reduced cost).

> It's unlikely running it on K8S (which is itself going to run on underpowered VMs with networked storage) is going to help.

On GCP, at least, you can provision a GKE node-pool where the nodes have direct-attached NVMe storage; deploy a privileged container that formats and RAID0s up the drives; and then make use of the resulting scratch filesystem via host-mounts.

Re: Why we moved from AWS RDS to Postgres in Kubernetes

#46
post #23

Ah, the 'ol sunk cost fallacy of infrastructure. We are already investing in supporting K8s, so let's throw the databases in there too. Couldn't possibly be that much work. Sure, a decade-old dedicated team at a billion-dollar multinational corporation has honed a solution designed to support hundreds of thousands of customers with high availability, and we could pay a little bit extra money to spin up a new database…

Quoted post unavailable.

[deleted]

Re: Why we moved from AWS RDS to Postgres in Kubernetes

#47
post #7
post #4

Having recently heard a lot of about PostgreSQL in Kubernetes (cloudNativePG for example) it always makes me wonder about the actual load and the complexity of the cluster in the question. > This is the reason why we were able to easily cope with 2M+ requests in less than 24h when Midnight Society launched This gives the answer, while it's probably not evenly distributed gives 23 req/sec (guess peak 60 - 100 might be…

> 23 req/sec (guess peak 60 - 100 might be already stretching it) That kind of load is something a decent developer laptop with an NVME drive can serve, nothing to write home about. It is sad that the "cloud" and all these supposedly "modern" DevOps systems managed to redefine the concept of "performance" for a large chunk of the industry.

Depends on the queries. Point queries that take 1ms each? Sure. Analytical queries that take 1000ms+ each? Not so much.

Re: Why we moved from AWS RDS to Postgres in Kubernetes

#48
post #38
post #27

Earlier quoted context omitted.

Running a statefull service in K8S is its own ball of wax

It is, but then I never understood why on earth you'd use k8s if you don't have stateful services. I mean really, what's the point?

Because it's easy? What alternative would you suggest?

Re: Why we moved from AWS RDS to Postgres in Kubernetes

#49
post #26

Earlier quoted context omitted.

AWS RDS is 10x slower than BareMetal MySQL (both reads and writes). Slowness is mainly due to the reason that Storage is over network for RDS. Not bad to invest some extra time to get better performance. You are falling to “Appeal to antiquity” fallacy if you think something old is better.

It's unlikely running it on K8S (which is itself going to run on underpowered VMs with networked storage) is going to help. If you're gonna spend effort in running Postgres manually, do it on bare-metal and at least get some reward out of it (performance and reduced cost).

> It's unlikely running it on K8S (which is itself going to run on underpowered VMs with networked storage) is going to help.

What?? We run replicated Patroni on local NVMEs and it's incredibly fast.

Re: Why we moved from AWS RDS to Postgres in Kubernetes

#50
post #34
post #7

Earlier quoted context omitted.

> 23 req/sec (guess peak 60 - 100 might be already stretching it) That kind of load is something a decent developer laptop with an NVME drive can serve, nothing to write home about. It is sad that the "cloud" and all these supposedly "modern" DevOps systems managed to redefine the concept of "performance" for a large chunk of the industry.

I can't blame it on "cloud", though it's not helping that there are an awful lot of cloud services that claim to be "high performance" and are often mediumish at best. But in general I see a lot of ignorance in the developer community as to how fast things should be able to run, even in terms of reading local files and doing local manipulations with no "cloud" in sight. Honestly, if I had to pin it on just one thing,…

Are you talking about the cloud host to cloud host networking or the POD networking inside the single host ?

The dizzying amount of NAT layers has to be killing performance. I haven't had the chance to ever sit down and unravel a system running a good load. The lack of TCP tuning combined with the required connection tracking is interesting to think about

Post reply on HN