ChatGPT na PostgreSQL – jak zbudować bazę dla 800 mln użytkowników?

Czy naprawdę trzeba budować własną bazę planetarną, żeby obsłużyć 800 milionów użytkowników? A może wystarczy „nudny” Postgres, trochę dyscypliny i kilka sprytnych sztuczek.

OpenAI oparło newralgiczne systemy ChatGPT na PostgreSQL. Według jednego z opracowań, do obsługi ruchu rzędu 800 mln użytkowników miesięcznie wystarczyło niemal 50 replik odczytowych, rygorystyczne limity i brak pośpiechu w stronę shardingu. Na POSETTE 2025 inżynierowie pokazali, jak z klasycznej, pojedynczej bazy i chmury Azure wycisnąć zdumiewająco dużo – bez wymiany silnika w locie.

To ważne, bo w świecie „hiperskali” łatwo uwierzyć, że jedyną drogą jest egzotyczna technologia i wielka migracja. Historia ChatGPT przypomina o czymś bardziej przyziemnym: do pewnego pułapu dalej wygrywa prostota, a największym lewarem są operacyjne nawyki. Inaczej mówiąc, zanim rozbijesz dane na tysiąc shardów, sprawdź, czy wyczerpałeś stare, dobre rzemiosło.

Skąd ta moc w Postgresie

Na starcie architektura była podręcznikowa: zarządzany Azure Database for PostgreSQL, jedna instancja główna (zapis), do tego wiele replik (odczyt). Taki układ jest dobry na obciążenia czytające – replik można dołożyć „do tuzina i dalej”, a geograficzne rozmieszczenie daje szybkie odpowiedzi użytkownikom na całym globie. Problem pojawia się, gdy rosną zapisy: wszystkie muszą przejść przez prymariusza. I tu trafiono na znany sufit – incydenty wydajnościowe stały się sygnałem alarmowym. [2]

Skala bez shardingu? Tak, ale z głową

Zamiast natychmiastowej dystrybucji danych na wiele shardów, zespół wybrał ścieżkę stopniowego odciążania zapisów i agresywnego skalowania odczytów. Według relacji, działało to w oparciu o prawie 50 replik i dbałość o niemal zerowy lag replikacji – bo co z tego, że mamy wiele kopii, jeśli spóźniają się z rzeczywistością. To wymagało skrupulatnego monitoringu i strojenia.

Największym problemem okazał się nie „ruch”, tylko MVCC, czyli wielowersyjność, która przy dużym wolumenie zapisów potrafi generować bloat tabel i podbijać koszty I/O. Recepta? Przycięcie zbędnych zapisów u źródła, planowanie w czasie cięższych operacji oraz odciążanie zadań piszących tam, gdzie to możliwe. Do tego higiena Postgresa: autovacuum precyzyjnie skonfigurowany, sensowne ustawienia work_mem i effective_cache_size. To nie magia – to solidny serwis.

Operacyjna dyscyplina zamiast magii

Drugi filar to zarządzanie odczytami. Skoro większość ruchu to czytanie, niech repliki robią swoje. Poszli dalej: kategoryzacja ruchu i wydzielone repliki dla zapytań o najwyższym priorytecie. Do tego porządek w połączeniach (PgBouncer) i systematyczne odchudzanie wolnych zapytań. Efekt? Jak ujęto to na konferencji: przejście z trybu „gasimy pożary” do „mamy to pod kontrolą”.

By system nie rozpadł się pod własnym ciężarem, doszły mechanizmy higieny operacyjnej: ścisłe reguły zmian schematu, zarządzanie długimi transakcjami, limity na poziomie aplikacji, połączeń i samych zapytań oraz wysoka dostępność z pudełka dzięki zarządzanemu środowisku. To nie są rzeczy efektowne. To te, które sprawiają, że w poniedziałek rano system nadal odpowiada.

Timeouty, czyli cichy bohater

Warto odnotować jeszcze jednego sojusznika: limity czasowe. Bezczynne lub wiszące zapytania potrafią zjadać zasoby. Konsekwentna polityka idle timeout i query timeout sprawia, że baza nie zamienia się w korek zasobów. To drobiazg, ale przy tej skali drobiazgi rządzą kalendarzem awarii.

A co z „niemożliwym”?

Jeśli wierzyć opisom, mówimy o obsłudze rzędu 800 milionów użytkowników miesięcznie bez egzotycznych rozwiązań, bez wczesnego shardingu, za to z blisko 50 replikami i konsekwencją w operacjach. Brzmi jak „z łatwością”? Tytułowe „with ease” jest raczej marketingową hiperbolą. Pod spodem leży miesiącami dopracowywana orkiestracja: od przycinania zapisów, przez polityki timeout, po kulturę zmian schematu. To nie „łatwość” – to dojrzałość.

Lekcja dla reszty świata

• Prostota skaluje się zaskakująco daleko. Jedna baza i wiele replik wystarczy, jeśli umiesz chronić prymariusza przed nadmiarem zapisów.
• Sharding jest opcją, ale drogą kosztowną operacyjnie. Jeśli nie musisz – nie zaczynaj od niego.
• Dyscyplina operacyjna to funkcja, nie dodatek. Limity, kolejki priorytetów, pooling i zasady zmian schematu są tak samo ważne jak indeksy.
• Chmura zarządzana nie załatwia wszystkiego, ale daje solidny grunt: HA, backupy, szybkie dokładanie replik i geograficzną dystrybucję.

Podsumowując: ChatGPT nie obala praw fizyki baz danych, tylko pokazuje, jak daleko można dojechać sprawnym prowadzeniem. Postgres w tej historii nie jest cudownym wynalazkiem, tylko sprawdzonym narzędziem, któremu dano odpowiednie ustawienia i plan. Zanim więc zaczniesz rozważać wielką migrację, zadaj sobie jedno pytanie: czy naprawdę potrzebujesz nowego silnika, czy może wystarczy dobrze ustawić to, co masz?

Źródła

• [1] https://opentools.ai/news/chatgpt-pushes-postgresql-to-the-limits-scaling-to-800-million-users-with-ease
• [2] https://microsoft.com/en-us/startups/blog/openai-and-postgresql-scaling-with-microsoft-azure/
• [3] https://skywork.ai/skypage/en/postgresql-ai-engineer-database-mastery/1979013584780906496