PostgreSQL v OpenAI a skalovani

[Tomas Hermanek]

Ahoj,

narazil jsem na zajímavý článek o používání PostgreSQL v OpenAI, kde řeší provoz pro 800 milionů uživatelů:

https://openai.com/index/scaling-postgresql/

Tom

[Josef Šimánek]

pá 23. 1. 2026 v 9:44 odesílatel Tomas Hermanek <herma...@gmail.com> napsal:

>
> Ahoj,
>
>
> narazil jsem na zajímavý článek o používání PostgreSQL v OpenAI, kde řeší provoz pro 800 milionů uživatelů:
>
> https://openai.com/index/scaling-postgresql/

Zajímavý to určitě je. Díky za sdílení!

Pár postřehů:

> For example, when a query updates a tuple or even a single field, the entire row is copied to create a new version.

Neměl by to řešit HOT update? Asi o tom budou vědět, takže škoda že
nerozepsali, proč zrovna v jejich nasazení to nefunguje.

> For write traffic, we’ve migrated shardable, write-heavy workloads to sharded systems such as Azure CosmosDB.

> Schema changes are restricted to existing tables. If a new feature requires additional tables, they must be in alternative sharded systems such as Azure CosmosDB rather than PostgreSQL.

> The primary rationale is that sharding existing application workloads would be highly complex and time-consuming, requiring changes to hundreds of application endpoints and potentially taking months or even years.

Celý článek má takový divný nádech zklamání ze škálování PostgreSQL
pro zápis a v podstatě ho opouští a přechází na Azure Cosmos DB.
Všechny nové tabulky už jdou rovnou na Cosmos DB.

> Many of these problematic queries are generated by Object-Relational Mapping frameworks (ORMs), so it’s important to carefully review the SQL they produce and ensure it behaves as expected.

Takový malý pozdrav pro všechny fanoušky Active Recordu a podobných. :)

>
> Tom
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
> Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/9b0ed275-03df-4082-9cdb-573717ab54f4n%40googlegroups.com.

[Pavel Stehule]

pá 23. 1. 2026 v 13:59 odesílatel Josef Šimánek <josef....@gmail.com> napsal:

pá 23. 1. 2026 v 9:44 odesílatel Tomas Hermanek <herma...@gmail.com> napsal:
>
> Ahoj,
>
>
> narazil jsem na zajímavý článek o používání PostgreSQL v OpenAI, kde řeší provoz pro 800 milionů uživatelů:
>
> https://openai.com/index/scaling-postgresql/

Zajímavý to určitě je. Díky za sdílení!

Pár postřehů:

> For example, when a query updates a tuple or even a single field, the entire row is copied to create a new version.

Neměl by to řešit HOT update? Asi o tom budou vědět, takže škoda že
nerozepsali, proč zrovna v jejich nasazení to nefunguje.

Tohle hot update urcite nedela

(2026-01-23 14:04:52) postgres=# create table x(a int, b int);
CREATE TABLE
(2026-01-23 14:05:12) postgres=# insert into x values(10,10);
INSERT 0 1
(2026-01-23 14:05:24) postgres=# select ctid, * from x;
┌───────┬────┬────┐
│ ctid  │ a  │ b  │
╞═══════╪════╪════╡
│ (0,1) │ 10 │ 10 │
└───────┴────┴────┘
(1 row)

(2026-01-23 14:05:30) postgres=# update x set b = 20;
UPDATE 1
(2026-01-23 14:05:40) postgres=# select ctid, * from x;
┌───────┬────┬────┐
│ ctid  │ a  │ b  │
╞═══════╪════╪════╡
│ (0,2) │ 10 │ 20 │
└───────┴────┴────┘
(1 row)

podle mne muselo dojit k hot update, a stejne doslo k vytvoreni nove verze. a podle statistik doslo k hot_update. hot update neznamena, ze se nevytvori nova verze v tabulce. Nemely by se ale vytvorit nove reference na novou verzi v indexech.

 

> For write traffic, we’ve migrated shardable, write-heavy workloads to sharded systems such as Azure CosmosDB.

> Schema changes are restricted to existing tables. If a new feature requires additional tables, they must be in alternative sharded systems such as Azure CosmosDB rather than PostgreSQL.

> The primary rationale is that sharding existing application workloads would be highly complex and time-consuming, requiring changes to hundreds of application endpoints and potentially taking months or even years.

Celý článek má takový divný nádech zklamání ze škálování PostgreSQL
pro zápis a v podstatě ho opouští a přechází na Azure Cosmos DB.
Všechny nové tabulky už jdou rovnou na Cosmos DB.

Cosmos je NoSQL cloud db - ta z principu musi vyrazne lepe skalovat - relacni databaze skalovat nikdy nebudou. Navic v dobach, kdy vznikala architektura Postgresu - at uz v 70 letech nebo v 80 tych, tak nikdo nebral v potaz moznou existenci cloudu. Myslim si, ze na Neonu nebo na Aurore Postgres by asi dostali lepsi vysledky. 

Dalsi otazkou je jaky maji datovy model. Jestli je to normalizovane schema nebo neco nad jsonem nebo jsonb. Treba casty update json nebo jsonb fieldu zvlast pokud je ten json delsi, tak je dost pomaly. Nebo jestli maji nejakou verzi EAV. 

 

> Many of these problematic queries are generated by Object-Relational Mapping frameworks (ORMs), so it’s important to carefully review the SQL they produce and ensure it behaves as expected.

Za sebe povazuju za zazrak a muselo to dat dost prace, ze jim to nejak utahne 800 mil uzivatelu. I kdyz je otazkou, co to znamena.  

Takový malý pozdrav pro všechny fanoušky Active Recordu a podobných. :)

>
> Tom
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
> Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/9b0ed275-03df-4082-9cdb-573717ab54f4n%40googlegroups.com.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFp7QwovWhRDcwT2NsmJcAmfrPWk_PAGjqb9tLWN3HPgapeXzg%40mail.gmail.com.

[David Turoň]

Ano, tak jak pise Pavel, HOT update - znamena, ze se predesly radek oznaci za smazany a novy radek je na stejne strance - bud tam bylo misto, nebo tam bylo neco smazano a vacuum to uvolnilo nebo se na strance nechava misto zamerne fill_factor .... Ale stejne plati, pokud je zmenena jen jedna hodnota v sloupci musi se udelat cely novy radek jako kopii... otazka zni kde jestli na stejne strance a tak se jen v indexu rekne ze je novy dale nebo na jine strance a musi dojit k uprave indexu.

David

pá 23. 1. 2026 v 14:37 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRDZVR2D%2BW5fidgvpfbkcdJzL4MbEQeVC7c%2BFcWxMnCRrg%40mail.gmail.com.

[David Turoň]

napsal jsem to spatne link je na strance na index se nesaha

https://www.cybertec-postgresql.com/en/hot-updates-in-postgresql-for-better-performance/

David

Dne pá 23. 1. 2026 15:01 uživatel David Turoň <turon...@gmail.com> napsal:

[Pavel Stěhule]

Dne pátek 23. ledna 2026 v 13:59:41 UTC+1 uživatel josef....@gmail.com napsal:

pá 23. 1. 2026 v 9:44 odesílatel Tomas Hermanek <herma...@gmail.com> napsal:
>
> Ahoj,
>
>
> narazil jsem na zajímavý článek o používání PostgreSQL v OpenAI, kde řeší provoz pro 800 milionů uživatelů:
>
> https://openai.com/index/scaling-postgresql/

Zajímavý to určitě je. Díky za sdílení!

Pár postřehů:

> For example, when a query updates a tuple or even a single field, the entire row is copied to create a new version.

Neměl by to řešit HOT update? Asi o tom budou vědět, takže škoda že
nerozepsali, proč zrovna v jejich nasazení to nefunguje.

> For write traffic, we’ve migrated shardable, write-heavy workloads to sharded systems such as Azure CosmosDB.

V diskuzi na linkedinu je uvedeno, ze v podstate nemaji zadny sharding - zapisuji do primaru a ctou z nekolika desitek replik.

Nedovedu si uplne predstavit, jak jim to muze realne fungovat. Dovedu si predstavit nasazeni Postgresu, tak jak to mel napriklad Skype.