Live data from Hacker News

Scaling PostgreSQL to power 800M ChatGPT users

openai.com

61–70 of 145 posts

Re: Scaling PostgreSQL to power 800M ChatGPT users

#61
post #37

Earlier quoted context omitted.

This article has very little useful information... There's nothing novel about optimizing queries, sharding and using read replicas.

It has one piece of useful info: their main data store even for 800M users is a single instance of postgres (for writes) without sharding.

when I joined twitter in 2011 there was a single mysql master user (not tweets) database and a few dozen read replicas. it was writing about 7000 updates per second and during bursts it would go too high for the single-threaded replication in mysql at the time to keep up with the master which would cause replication lag and all kinds of annoying things in the app. you just have to pick the right time to make the switch before it is an emergency.

Re: Scaling PostgreSQL to power 800M ChatGPT users

#62
I would be super curious about:

How do they store all the other stuff related to operating the service? This must be a combination of several components? (yes, including some massdata storage, Id guess?)

This would be cool to understand, as Ive absolutely no idea how this is done (and could be done :-)

Re: Scaling PostgreSQL to power 800M ChatGPT users

#63

This is why I love Postgres. It can get you to being one of the largest websites before you need to reconsider your architecture just by throwing CPU and disk at it. At that point you can well afford to hire people who are deep experts at sharding etc.

> At that point you can well afford to hire people who are deep experts at sharding etc.

Can you, though? OpenAI is haemorrhaging money like it is going out of style and, according to the news cycle over the last couple of days, will likely to be bankrupt by 2027.

Re: Scaling PostgreSQL to power 800M ChatGPT users

#65
post #16

Earlier quoted context omitted.

I know they said that, but in fact sharding is entirely a database-level concern. The application need not be aware of it at all.

Sharding can be made mostly transparent, but it's not purely a DB-level concern in practice. Once data is split across nodes, join patterns, cross-shard transactions, global uniqueness, certain keys hit with a lot of traffic, etc matter a lot. Even if partitioning handles routing, the application's query patterns and its consistency/latency requirements can still force application-level changes.

> mostly transparent, but it's not purely a DB-level concern in practice ...

But how would any of that change by going outside Postgres itself to begin with? That's the part that doesn't make much sense to me.

Re: Scaling PostgreSQL to power 800M ChatGPT users

#66
Running this on Azure Postgresql, even migrating to CosmosDB, cannot be cheap. I know that OpenAI have to deal/relationship with Microsoft, but still, this has to be expensive.

This is however the most down to earth: How we scale Postgresql I've read in a long time. No weird hacker, no messing around with the source code or tweaking the Linux kernel. Running on Azure Postgresql it's not like OpenAI have those options anyway, but still it seems a lot more relatable than: We wrote our own drive/filesystem/database-hack in Javascript.

Re: Scaling PostgreSQL to power 800M ChatGPT users

#67
Out of pure boredom and tired of all these Chat websites selling my data and with ChatGPT's new update on ads - I decided enough was enough and created my own Chat application for privacy. Like every other architect, I searched for a good database and eventually gave up on specialized ones for chat because they were either too expensive to host or too complex to deal with. So, I simply just used PostgreSQL. My chat app has basic RAG, not ground breaking or anything - but the most important feature I made was ability to add different chat models into one group chat. So, when you ask for opinions on something - you are not relying on just a single model and you can get a multi-model view of all the possible answers. Each model can have its own unique prompt within the group chat. So basically, a join table.

Months passed by since this application was developed (a simple Phoenix/Elixir backend), and yesterday I was casually checking my database to see how many rows it had - about 500,000+ roughly. I didn't notice a single hint of the volume the Postgres was handling, granted - I'm the only user, but there's always a lot going on - RAG, mostly that requires searching of the database for context before multiple agents send you a response (and respond amongst themselves). Absolutely zero performance degradation.

I'm convinced that Postgres is a killer database that doesn't get the attention it deserves over the others (for chat). Already managing some high traffic websites (with over 500M+ requests) with no issues, so I am extremely unsurprised that it works really well for chat apps at scale too.

Re: Scaling PostgreSQL to power 800M ChatGPT users

#68
post #44

Earlier quoted context omitted.

The major hyperscalers all offer a plethora of virtual machines SKUs that are essentially one entire two-socket box with many-core CPUs. For example, Azure Standard_E192ibds_v6 is 96 cores with 1.8 TB of memory and 10 TB of local SSD storage with 3 million IOPS. Past those "general purpose" VMs you get the enormous machines with 8, 16, or even 32 sockets.[1] These are almost exclusively used for SAP HANA in-memory da…

Are there any pictures around of these 8, 16, 32 socket boards? Just curious how they look like.

The individual motherboards have only four sockets: https://assets.ext.hpe.com/is/image/hpedam/s00012647?$zoom$#...

Multiple of these can be linked together with “NUMALink” cables, which carry the same protocol as the traces that go between sockets on the motherboard. You end up with a single kernel running across multiple chassis.

Re: Scaling PostgreSQL to power 800M ChatGPT users

#70
"This effort demonstrates that with the right design and optimizations, Azure PostgreSQL can be scaled to handle the largest production workloads."

Sure, but choosing from the start a DB that can scale with ease would have taken far less time and effort.

You can bend any software into doing anything, but is it worth it?

Post reply on HN