OpenAI Membuktikan PostgreSQL Bisa Tangani 800 Juta Pengguna
Dalam dunia teknologi yang sering terpaku pada solusi database terdistribusi dan terfragmentasi (sharding), OpenAI justru mengambil pendekatan berbeda. Perusahaan di balik ChatGPT ini mengungkapkan bahwa mereka menjalankan platform API dan ChatGPT untuk 800 juta pengguna pada satu instance utama PostgreSQL. Bukan cluster terdistribusi, bukan pula sistem yang di-shard, melainkan satu Azure PostgreSQL Flexible Server yang menangani semua operasi tulis (write).
Arsitektur yang Menantang Konvensi
Hampir 50 replika baca (read replicas) yang tersebar di berbagai wilayah menangani permintaan baca. Sistem ini memproses jutaan kueri per detik dengan mempertahankan latensi p99 di kisaran dua digit milidetik dan ketersediaan 99,999% (five-nines). Pengaturan ini menantang kebijaksanaan konvensional tentang penskalaan dan menawarkan wawasan berharga bagi arsitek enterprise tentang apa yang benar-benar berfungsi pada skala masif.
Pelajaran di sini bukan untuk menyalin tumpukan teknologi OpenAI. Intinya adalah bahwa keputusan arsitektural harus didorong oleh pola beban kerja dan batasan operasional, bukan oleh kepanikan akan skala atau pilihan infrastruktur yang sedang tren. Pengaturan PostgreSQL OpenAI menunjukkan sejauh mana sistem yang telah teruji dapat diregangkan ketika tim mengoptimalkan dengan sengaja alih-alih mendesain ulang secara prematur.
Optimasi Kunci di Balik Skala Besar
OpenAI mencapai skala ini melalui serangkaian optimasi yang ditargetkan:
- Connection Pooling: Memotong waktu koneksi dari 50 milidetik menjadi hanya 5 milidetik.
- Cache Locking: Mencegah masalah ‘thundering herd’ di mana cache miss memicu kelebihan beban database.
- Strategi Hybrid: Tidak ada tabel baru di PostgreSQL. Beban kerja baru default ke sistem ter-shard seperti Azure Cosmos DB. Beban kerja berat-tulis yang ada yang dapat dipartisi secara horizontal dipindahkan keluar. Sisanya tetap di PostgreSQL dengan optimasi agresif.
Mengapa PostgreSQL Tetap Relevan untuk Enterprise
PostgreSQL menangani data operasional untuk ChatGPT dan platform API OpenAI. Beban kerja sangat berorientasi pada baca, yang membuat PostgreSQL cocok. Namun, Multiversion Concurrency Control (MVCC) PostgreSQL menciptakan tantangan di bawah beban tulis yang berat. Alih-alih melawan keterbatasan ini, OpenAI membangun strateginya di sekitarnya.
Pada skala OpenAI, pertukaran ini bukanlah teoritis — mereka menentukan beban kerja mana yang tetap berada di PostgreSQL dan mana yang harus pindah ke tempat lain. Pendekatan ini menawarkan perusahaan alternatif praktis dari arsitektur ulang secara keseluruhan. Daripada menghabiskan waktu bertahun-tahun menulis ulang ratusan endpoint, tim dapat mengidentifikasi hambatan spesifik dan hanya memindahkan beban kerja tersebut ke sistem yang dibuat khusus.
Praktik Terbaik yang Dapat Diadopsi Perusahaan
Pengalaman OpenAI menskalakan PostgreSQL mengungkapkan beberapa praktik yang dapat diadopsi perusahaan terlepas dari skala mereka:
- Bangun Pertahanan Operasional di Berbagai Lapisan: Kombinasikan penguncian cache, connection pooling, dan pembatasan kecepatan (rate limiting) di tingkat aplikasi, proxy, dan kueri. Isolasi beban kerja mengarahkan lalu lintas prioritas rendah dan tinggi ke instance terpisah.
- Tinjau dan Pantau SQL yang Dihasilkan ORM di Produksi: OpenAI menemukan satu kueri yang dihasilkan ORM yang menggabungkan 12 tabel dan menyebabkan beberapa insiden berbahaya tinggi ketika lalu lintas melonjak. Kenyamanan membiarkan kerangka kerja menghasilkan SQL menciptakan risiko penskalaan tersembunyi.
- Terapkan Disiplin Operasional yang Ketat: Hanya izinkan perubahan skema ringan — apa pun yang memicu penulisan ulang tabel penuh dilarang. Kueri yang berjalan lama dihentikan secara otomatis. Saat mengisi data ulang (backfilling), mereka memberlakukan batasan kecepatan yang sangat ketat.
Kesimpulan: Fokus pada Pola Beban Kerja, Bukan Jumlah Pengguna
Beban kerja berat-baca dengan tulis secara sporadis dapat berjalan di PostgreSQL single-primary lebih lama dari yang biasa diasumsikan. Keputusan untuk memecah (shard) harus bergantung pada pola beban kerja daripada jumlah pengguna. Pendekatan ini sangat relevan untuk aplikasi AI, yang sering kali memiliki beban kerja sangat berorientasi baca dengan lonjakan lalu lintas yang tidak terduga. Pelajarannya sederhana: identifikasi hambatan aktual, optimalkan infrastruktur yang terbukti jika memungkinkan, dan migrasikan secara selektif jika diperlukan. Arsitektur ulang secara keseluruhan bukan selalu jawaban untuk tantangan penskalaan.