OpenAI: PostgreSQL’ü shard etmeden ölçek sınırlarını aşmak

 (pixelstech.net)
35 puan yazan GN⁺ 2025-05-24 | 2 yorum | WhatsApp'ta paylaş
  • OpenAI, PostgreSQL’ü sharding olmadan kullanırken yüz milyonlarca kullanıcının trafiğini etkili biçimde nasıl işlediğini PGConf.dev 2025’te paylaştı
  • Yazma darboğazı sorununu çözmek için yazmaları dağıtma, sorgu optimizasyonu, şema yönetimi gibi çeşitli yaklaşımlar benimsedi
  • Başlıca sorunlar olarak MVCC tasarımının tablo/indeks şişmesi, WAL nedeniyle replikasyon gecikmesi gibi PostgreSQL mimarisinin sınırları ve operasyonel zorluklar belirtildi
  • Okuma yükünü dağıtma, uzun transaction’ları sınırlama ve ORM kullanımını en aza indirme gibi sorgu optimizasyonu stratejileri öne çıkıyor
  • OpenAI, coğrafi olarak dağıtılmış 40’tan fazla replika üzerinden 1 milyon QPS’ye ulaşıyor ve arıza durumlarında da yüksek erişilebilirlik sağlıyor

OpenAI’nin PostgreSQL’i büyük ölçekte ölçeklendirme örneği

Arka plan

  • OpenAI’nin birçok temel hizmeti PostgreSQL’e dayanıyor
  • Veritabanı arızası yaşanması durumunda bu, tüm hizmetleri doğrudan etkiliyor
  • Geçmişte ChatGPT dahil başlıca hizmetlerde PostgreSQL sorunları nedeniyle kesinti yaşandığı oldu
  • OpenAI, Azure yönetilen veritabanı üzerinde Primary-Replica mimarisi (tek bir Primary + 40’tan fazla Replica) işletiyor
  • Aylık 500 milyon aktif kullanıcının bulunduğu bir ortamda ölçeklenebilirlik, iş başarısının temel unsurlarından biri

Başlıca zorluklar

  • Okuma trafiği çok sayıda Replica arasında dağıtılabilirken, yazma istekleri tek bir Primary üzerinde yoğunlaşıyor ve darboğaz oluşturuyor
  • Başlıca iyileştirme noktaları
    • Mümkün olan tüm yazma isteklerini offload ederek dağıtmak
    • Yeni servislerin Primary DB’ye ek bağlantı kurmasını en aza indirmek
  • MVCC (çok sürümlü eşzamanlılık kontrolü) yapısı gereği tablo/indeks şişmesi, karmaşık garbage collection ayarı ve indeks görünürlük kontrolleri gibi dezavantajlar bulunuyor
  • Replica sayısı arttıkça WAL (Write-Ahead Logging) trafiği de hızla artıyor ve ağ bant genişliği yeni bir darboğaz haline geliyor

Alınan önlemler

Primary veritabanı yükünü dağıtma

  • Yazma yükünü öngörme ve hafifletme:
    • Mümkün olan tüm yazmaları offload etme
    • Uygulama seviyesinde gereksiz yazmaları engelleme
    • Lazy Write uygulama, veri backfill periyotlarını ayarlama
  • Okuma yükü mümkün olduğunca Replica’lara dağıtılıyor; kaçınılmaz olarak Primary üzerinde işlendiğinde ise yüksek verimlilik gerekiyor

Sorgu optimizasyonu

  • Uzun transaction’lar sistem kaynaklarını uzun süre işgal ediyor ve garbage collection gecikmesine yol açıyor
  • Oturum/sorgu/istemci bazında Timeout uygulanıyor, idle in transaction oturumları sınırlandırılıyor
  • ORM kullanımı durumunda verimsizliğin artabileceği açıkça belirtiliyor; dikkatli kullanılması tavsiye ediliyor
  • Karmaşık multi-join sorgularında (ör. 12 tablonun join edilmesi) optimizasyon yapıldı

Tek hata noktası (SPOF) ile başa çıkma

  • Primary arızalandığında yazma yapılamıyor; Replica’lar ise kısmi arızalarda bile okuma sürekliliğini koruyor
  • Önemli istekler (yüksek öncelik) özel Replica’larda işleniyor, düşük öncelikli isteklerin etkisi en aza indiriliyor

Şema yönetimi

  • Yeni tablo oluşturma ve yeni iş yükü ekleme, cluster üzerinde sınırlandırılıyor
  • Sütun ekleme/kaldırmada yalnızca 5 saniye sınırı içinde kalan hafif işlemlere izin veriliyor; tüm tabloyu yeniden yazmayı gerektiren işlemler yasak
  • İndeks oluşturma/kaldırma yalnızca CONCURRENTLY seçeneğiyle yapılabiliyor
  • 1 saniyeden uzun süren sorguların şema değişikliklerini sürekli bloklaması sorunu görülüyor; bu nedenle uygulama katmanında bu tür sorguların optimize edilmesi veya offload edilmesi gerekiyor

Operasyon sonuçları

  • Tüm cluster genelinde 1 milyon QPS (okuma+yazma) işleniyor ve OpenAI’nin başlıca hizmetleri destekleniyor
  • 40’tan fazla Replica eklenmesine rağmen replikasyon gecikmesi artmadı
  • Farklı region’lara Read-only Replica yerleştirilerek düşük gecikme korundu
  • Son 9 ayda PostgreSQL ile ilgili yalnızca 1 adet SEV0 arızası yaşandı
  • Gelecekteki büyüme için gerekli kapasite güvence altına alındı

Arıza örnekleri

  • Cache başarısızlığı kaynaklı cascading effect
  • Yüksek CPU kullanımı sırasında WALSender sürecinin WAL iletimini durdurup döngü durumuna girmesine neden olan bir bug → replikasyon gecikmesi

PostgreSQL için önerilen özellik iyileştirmeleri

  1. İndeks yönetimi: Gereksiz indeksleri silmeden önce riski azaltmak için güvenli bir devre dışı bırakma özelliği önerisi
  2. Gözlemlenebilirlik: p95, p99 gibi latency histogramı/yüzdelik dilim tabanlı metriklerin sunulması talebi
  3. Şema değişikliği geçmişi: DDL gibi şema değişikliklerinin geçmişini saklama özelliği ihtiyacı
  4. İzleme görünümlerinin anlamının netleştirilmesi: Belirli bir oturumun uzun süre ClientRead durumunda kalmasının nedeni ve nasıl ele alınacağına dair soru
  5. Varsayılan parametre optimizasyonu: PostgreSQL’in varsayılan değerlerinin fazla muhafazakâr olduğu, daha iyi varsayılanlar veya heuristics talep edildiği belirtildi

Lao Feng’in yorumu

  • OpenAI’nin bu tür uç koşullardaki ölçekleme stratejisi, çekirdek PostgreSQL geliştiricileri için anlamlı bir gerçek dünya kullanım örneği sunuyor
  • Çin’deki Tantan gibi büyük ölçekli servislerde de benzer deneyimler var (33 Replica, 400 bin QPS, uygulama tarafında sharding kullanımı)
  • Günümüzün yüksek performanslı donanım ortamında, OpenAI örneğinde olduğu gibi tek bir PostgreSQL cluster ile de agresif ölçekleme mümkün; dağıtık veritabanı her zaman zorunlu değil
  • OpenAI, Azure yönetilen PostgreSQL, 40’tan fazla Replica, cross-region dağıtım ve Kubernetes + PgBouncer kullanıyor
  • Azure PostgreSQL ekibinden yoğun destek alsa da, hâlâ operasyon tarafında uygulama/DBA yetkinliği ve gözlemlenebilirlik kritik önem taşıyor
  • Datadog üzerinden izleme yapıldığı, bunun performans ve maliyet yükü doğurduğu da belirtildi
  • Operasyon bilgisi, başarısızlık deneyimi ve DBA birikimi, hizmet kalitesinin anahtarı

Lao Feng Soru-Cevap

İndeks devre dışı bırakma özelliği

  • PostgreSQL içinde indisvalid alanı ile indeksler devre dışı bırakılabilir; ancak superuser yetkisi gerekir ve RDS ortamında bu sınırlıdır
  • Pratik alternatif, izleme ile indeks kullanımını doğruladıktan sonra güvenli biçimde silmektir

Gözlemlenebilirliği genişletme: P95/P99 latency

  • pg_stat_statements içinde yüzdelik dilim metrikleri sunmak bellek ek yükü nedeniyle zordur; bunun yerine pg_stat_monitor, eBPF veya uygulama katmanında latency izleme gibi dolaylı yöntemler vardır
  • Azure yönetilen PostgreSQL ortamında bazı seçenekler (sunucu erişimi, eBPF vb.) desteklenmez

Şema değişikliği geçmişi

  • Log dosyaları, pgaudit, CREATE EVENT TRIGGER, pg_ddl_historization gibi araçlar kullanılabilir; ancak superuser yetkisi gerekir ve Azure RDS desteği sınırlıdır
  • İstenen biçim, sorgulanabilir bir sistem view/tablosu olarak geçmişin saklanmasıdır

İzleme görünümlerinin anlamı

  • State=Active + WaitEvent=ClientRead kombinasyonu, statement yürütülürken istemciden girdi beklenmesi anlamına gelir; bu her zaman bir bug değildir ve çeşitli nedenleri olabilir
  • Bağlantı açık kalma süresini sınırlamak (HAProxy gibi ağ katmanında bağlantı zaman aşımı ayarı, istemci connection pool ömrü yönetimi vb.) yan etkileri azaltabilir; Azure’da bunun desteklenip desteklenmediği net değil

Varsayılan parametreler

  • PostgreSQL’in varsayılanları fazla muhafazakârdır; ancak servis bazlı ayrıntılı heuristics veya otomatik parametre ayarı (RDS, Pigsty vb.) ile telafi edilebilir
  • Gelecekte PostgreSQL araçlarına donanım özelliklerini otomatik algılayıp uygulayan bir özellik eklenirse sahadaki yükün hafiflemesi bekleniyor

Kendi kendine işletim (self-hosting) seçeneği

  • Pratik operasyon sorunları, PostgreSQL’in kendisinden çok Azure yönetilen hizmetinin sınırlamalarından kaynaklanıyor
  • IaaS ortamında NVMe SSD tabanlı bir PostgreSQL cluster’ını şirket içinde kurmak (Pigsty vb.) işlevsel ve operasyonel esneklik sağlayabilir
  • Pigsty gibi çözümler kullanılırsa OpenAI’nin ihtiyaçlarının çoğu önceden karşılanabilir; bu nedenle ölçek ve gereksinimlere göre değerlendirmeye değer olduğu belirtiliyor

İlgili okumalar

2 yorum

 
GN⁺ 2025-05-24
Hacker News görüşü

  • Geçen hafta PGConf'a katıldım ve bu sunumun en kalabalık oturumlardan biri olması etkileyiciydi; özellikle de çoğu oturumun Postgres'in kendisinin geliştirilmesine odaklandığı, içe dönük bir konferans olduğu düşünülürse bu vaka sunumu oldukça taze hissettirdi. Bir ürün başarılı şekilde büyürken birçok ekibin yığının belirli bölümlerini nasıl ölçekleyeceğini derinlemesine bilmediğini her zaman akılda tutmak gerekiyor; bu sunum da küçük bir ekibin sorunları aşarken nasıl öğrenip ilerlediğini gösteren harika bir hikâyeydi. "Bunu böyle yapmamalı değil misiniz?" gibi indirgemeci tepkilerden ziyade, gerçek kullanıcı hikâyesi üzerinden büyüme sürecini ve ürünün yüksek popülerliğini canlı biçimde göstermesi açısından, iç geliştiricilere dönük bir etkinlik için tam yerinde bir oturumdu. Sunumun ana mesajı, yazma yükü çok fazla değilse, salt okunur düğümler (read replicas) ve tek bir master yapısıyla bile Postgres'in inanılmaz düzeyde okuma hacmine ölçeklenebileceğiydi. Bu mesajın aslında çoğu uygulama için geçerli olduğu savunuldu. Soru-cevap bölümünde ise çoğunlukla Postgres çekirdek geliştiricileri kullanım senaryosunu öğrenmeye yönelik sorular sordu; eleştirme niyeti neredeyse yoktu ve Postgres topluluğunun gerçekten nazik ve açık bir atmosfere sahip olduğu izlenimi edinildi

    • "Yazma yükü çok fazla değilse tek bir master ve salt okunur replikalarla Postgres'in okuma kapasitesi büyük ölçüde ölçeklenebilir" mesajı hakkında, sistem tasarımı mülakatları yaparken çok fazla adayın saniyede 5 okuma seviyesindeki basit bir sistem için bile devasa dağıtık yapılar ya da eninde sonunda tutarlılığı bozacak sistemlerle başlamaya çalıştığını gördüğünü söylüyor. On milyon kullanıcı aslında o kadar da büyük bir ölçek değil. Sektörün tamamı yatay ölçeklemeye odaklanmışken, gerçek donanımın hayal edilenden çok daha hızlı ve büyük hale geldiğini daha fazla kişinin fark etmesi gerektiği dile getiriliyor. Amazon'dan 32 TB RAM'li sunucu kiralanabilen bir dünyada yaşıyoruz. Ölçek büyüse bile ACID garantileri hâlâ fazlasıyla değerli

    • Bunun, sunumun gerçekten vermek istediği temel mesaj olduğunu söyleyip teşekkür ediyor (Bohan)

    • Bu sunumun slaytlarını ya da kaydını izleyebileceği bir yer olup olmadığını soruyor

    • Bu başlığın ilgili ekibe karşı biraz acımasız davrandığı izlenimini aldığını söyleyen bir görüş var. Bu alanda deneyimli HN kullanıcılarının, ChatGPT gibi büyük ölçekli bir hizmetin mimari olarak nasıl ölçeklendirildiğine ve neredeyse sınırsız kaynağa sahip bir şirketin nasıl işe alım yaptığına ilgi duyduğu açıklanıyor. "ORM kullanırsanız verimsiz sorgular kolayca ortaya çıkabilir, dikkatli olun" mesajının kendisi bile, söz konusu ekibin bu büyüklükte altyapı işletme konusunda henüz çok deneyimli olmadığının bir göstergesi olarak yorumlanıyor

  • Esneklik açısından self-hosting postgres cazip olsa da (süper kullanıcı yetkileri veya gelişmiş özelliklerden yararlanmak gibi), fiilen kendin işletmek biraz göz korkutucu geliyor. Bulut sağlayıcılarının da, bir indeksi gerçekten silmeden önce, sorgu planlayıcısında indeks devre dışı bırakma özelliğini standart olarak desteklemesi iyi olurdu. Büyük şirketler için yığını özelleştirmek adına self-hosting seçimi gayet makul olabilir

    • Postgres'te belirli bir indeksi kullanmak ya da devre dışı bırakmak için zaten çeşitli yöntemler var ve bunlar bulut yönetimli Postgres örneklerinde de kullanılabiliyor. Örneğin sorgu planlayıcı ayarlarını sorgu bazında değiştirmek (enable_indexscan=off gibi), where koşuluna basit aritmetik ekleyerek bilerek indeks kullanımını engellemek ve pg_hintplan eklentisiyle (yorum satırları üzerinden hangi indeksin kullanılacağına dair ipucu verilebiliyor, bkz: https://pg-hint-plan.readthedocs.io/en/latest/hint_table.html#hints-for-scan-methods)

    • (Azure Postgres ekibinde olduğunu belirterek) OpenAI self-host kullanmıyor, Azure'un yönetimli PostgreSQL hizmetini (Flexible Server) kullanıyor

    • OpenAI konuşmacısı (Bohan) bunu bizzat açıkladı; self-host bir ortam değil, Azure Database for PostgreSQL kullanıyorlar. Sunumda birkaç kez "Azure Postgres" denmiş olsa da, bunun Microsoft tarafından yönetilen bir hizmet olduğunu daha açık söylemeleri gerekirdi diyerek özür diliyor

    • MySQL ve MariaDB'de indeksleri INVISIBLE veya IGNORED olarak oluşturup sorgu planlayıcısının onları yok saymasını sağlayan DDL varken, Postgres'te benzer bir özelliğin olmaması şaşırtıcı bulunuyor

    • Sadece "Self-hosting postgres'un avantajı esnekliktir…" cümlesini alıntılıyor

  • Şema değişikliği olaylarının (kolon ekleme/silme vb.) geçmişini kaydetme ihtiyacına yanıt olarak, bunun EVENT TRIGGER kullanılarak gerçek zamanlı şekilde zaten yapılabildiği ve örnek uygulama olarak Aquameta'ya (https://github.com/aquametalabs/aquameta) bakılabileceği belirtiliyor

    • Biz de kendi Postgres ortamımızda DDL değişiklikleri için geçmiş takibi özelliği geliştiriyoruz. Postgres'in kendisi çok güçlü olduğu için bunu pek çok şekilde yapmak mümkün, ama geçmiş takibi ile büyük/önemli veritabanlarında operasyon kaydı (log) tutmak da son derece yaygın bir ihtiyaç. Çoğu kişi bunun önemini ancak bizzat acı şekilde deneyimledikten sonra fark ediyor. Sadece DDL değişiklikleri değil, önemli operasyonel politikalar (ör. fiyat modeli değişikliği, SKU/fiyat özelleştirmeleri vb.) devreye girdiğinde de mutlaka "denetlenebilirlik" sağlanmalı. Tamamen ilişkisel model tasarladığınızda, gerçek uygulamalarda sık değişen tabloların az sayıda, çoğunun ise neredeyse hiç değişmeyen "statik" tablolar olduğu görülüyor; bu tablolar değiştiğinde geçmişlerini dikkatle kaydetmek, eski verileri yorumlamak ya da geri almak açısından avantaj sağlıyor

    • Biz (Xata), hem pgroll (https://github.com/xataio/pgroll) hem de pgstream (https://github.com/xataio/pgstream) içinde DDL değişikliklerini EVENT TRIGGER ile algılayıp şema migrasyon geçmişini tutma veya şema değişikliği olaylarını mantıksal çoğaltma akışına dahil etme özelliğini kullanıyoruz. Ancak Postgres tabanlı DBaaS hizmetlerinin çoğu, süper kullanıcı yetkileri nedeniyle EVENT TRIGGER desteğini kısmen sınırlandırıyor; RDS/Aurora ve Xata destekliyor, Supabase de destek hazırlığında

    • Aquameta'yı hatırladığınız için teşekkürler, yakında harika yeni özellikler geliyor diye ufak bir teaser veriyor

  • Bu içerikte geçen noktaların (büyük ölçekte eşzamanlı indeks oluşturma, tablo yeniden yazımından kaçınma, trafiği dağıtma, işlem zaman aşımları, okuma replikaları vb.) aslında OpenAI'dan çok daha küçük ölçekli işletimlerde bile neredeyse zorunlu, yani temel bilgi olduğu savunuluyor. Postgres'ten talep edilen özelliklerin de aslında uzun zamandır herkesin istediği şeyler olduğu, başlıkta "Next Level" dense de gerçekte yeni iş yüklerinin kısıtlı olduğu bir durumda tek master'ı ne pahasına olursa olsun koruyarak ölçeklemeye çalışma tablosuna daha yakın olduğu söyleniyor. Büyük okuma yükünü sorunsuz kaldırabilmenin asıl önemli nokta olduğu, ama bunun zaten okuma replikaları ve yatay dağıtımın standart yaklaşımı olduğu belirtiliyor. Bir indeksi devre dışı bırakma yöntemi olarak iç alan (indisvalid) değiştirmenin resmî olarak sunulan bir yol olmadığı ve bu tür sistem kataloğu müdahalelerinin tehlikeli olduğu uyarısı yapılıyor. İzleme görünümleriyle indeks kullanımını kontrol edip sonra silme yaklaşımının da kusursuz çözüm olmadığı; hangi indeksin gerekli ya da gereksiz olduğunu daha güvenilir biçimde anlamak için sorgu planlarına da bakmak gerektiği söyleniyor

    • TFA'de OpenAI'nin Azure üzerinde saniyede 1 milyon sorgu işlediği söyleniyor; bunun, gerçek bulut ortamında, özellikle ağ tabanlı depolama kullanılırken oldukça etkileyici olduğu yorumu yapılıyor. Ancak bunun toplamda yaklaşık 40 okuma replikasına dağıldığı düşünülürse, örnek başına yaklaşık 25 bin QPS ediyor ve bu yüzden o kadar da şaşırtıcı bulunmuyor. İndeks kullanımı tartışmasına gelince, güncel istatistikler ve veritabanı özellikleri doğru anlaşılıyorsa, hangi indeksin uygun olduğunu belirlemek için sorgunun koşul/projeksiyon yapısının indeksin left-most prefix düzenini takip edip etmediğine bakmanın yeterli olduğu açıklanıyor

    • OpenAI'nin neden Postgres sharding yapmadığına dair hiçbir açıklama olmaması sinir bozucu bulunuyor. Kullanıcı bazlı sharding bile işleri çok daha kolay çözebilirmiş gibi görünüyor; neden tek master'da ısrar ettikleri sorgulanıyor

  • Fiziksel replikasyon kullanıyor gibi görünüyorlar; ben ise şu anda maliyet düşürmek (bölgeler arası çıkış trafiğini azaltmak) amacıyla mantıksal replikasyona geçmeyi düşünüyorum. Postgres 17 sonrasında yerleşik mantıksal replikasyonun çok ilerlediği anlaşılıyor; pratikte denemeye değer mi diye görüş soruluyor

  • Farklı sorgu türlerine cevap verebilmek için başka depolama motorlarını da (anahtar-değer, arama, vektör arama, önbellek vb.) paralel kullanıyor olmaları gerekir; bu yüzden sunumun yalnızca Postgres'e odaklanması tuhaf bulunuyor. Gerçekte içeride trafik ve yük dağıtımı için çok daha çeşitli stratejiler uyguluyor olabilecekleri tahmin ediliyor

  • Sadece yazma örneğini yerel hızlı SSD takılı özel sunucularda doğrudan çalıştırıp, okumayı ise yalnızca yönetimli hizmette yapmak daha iyi performans sağlar mı diye merak ediliyor

  • "Biraz DB shard edin" şeklinde sert bir görüş var. Kullanıcı/organizasyon bazlı sharding bile yaşadıkları temel sorunları kolayca çözebilirmiş gibi görünüyor. Karmaşık dolambaçlı çözümleri tekrar tekrar denemenin aslında daha büyük bir dolaylı yol olduğu söyleniyor

    • Sunumda asıl mesajın, sharding yapmadan da tek master yapısıyla çok yüksek işlem hacimlerine kadar ölçeklenebildiğini göstermek olduğu; elbette sharding'in değerlendirildiği ama ödünleşimlerin buna değmediği ve mevcut yapının da ölçeklenebildiği anlatılıyor

    • OpenAI sunumcusu (Bohan) doğrudan yanıt veriyor: İş yükünü shard'lara bölmek kolay bir durum değil ve yüksek yazma yüküne sahip iş yükleri zaten PostgreSQL'den ayrılıp shard'larla işleniyor; geriye kalan kısım ise neredeyse salt okunur olduğu için sharding'e geçiş çok büyük çaba gerektiriyor. Şu an için yalnızca Azure Database for PostgreSQL ile bile yeterli ölçeklenebilirlik ve gelecekteki kapasite ihtiyacı karşılanabiliyor. Ancak uzun vadede sharding'i tamamen dışlamıyorlar; sadece kısa vadeli öncelik değil

    • Sharding'in düşünüldüğü kadar basit olmadığı savunuluyor. Güçlü bir veritabanı kullanma nedeni, karmaşık veri analizi ve sorgulama yapabilmek; amaç sadece basit depolama ve dağıtım olsaydı, birkaç NFS mount kullanmak çok daha kolay olurdu

    • Saniyede bir milyon sorgu gibi devasa bir veritabanına basitçe sharding uygulamayı önermenin o kadar kolay olmadığına dair gerçekçi bir geri bildirim var. Organizasyon bazlı yapılandırma doğal bir shard anahtarı gibi görünse de, bu ölçekte artık hiçbir şeyin basit olmadığı söyleniyor

    • Bu görüşe güçlü şekilde katıldığını belirten bir yanıt

  • Sunumda geçen ORM'leri dikkatli kullanma uyarısına karşılık, tüm ORM'lerin (özellikle çoklu veritabanı uyumluluğu hedefleyen ORM'lerin) sorunlu olduğunu düşündüğünü söylüyor. ORM kullanıldığında insanı veri desenlerini yalnızca uygulama kodu seviyesinde düşünmeye ittiğini ve sonuçta her veritabanının sunduğu güçlü özelliklerden neredeyse hiç yararlanılamadığını savunuyor. Kendisi hiç ORM kullanmıyor; Postgres'e özgü sorgu ve özellikleri aktif biçimde kullanıyor, dil ya da kullanım kolaylığından çok veritabanının gücüne odaklanmanın çok daha faydalı olduğunu söylüyor. Sonuç olarak iyi SQL'i doğrudan yazmanın tüm sistemi mutlu ettiği sonucuna varıyor

    • Eskiden DB2'den psql'e geçişte, kesinti süresini en aza indirmek için ORM'nin çok yardımcı olduğu bir deneyim anlatılıyor. ORM sayesinde veritabanı değişimi şeffaf oldu, mantığın büyük kısmına neredeyse hiç dokunmak gerekmedi; ayrıca tüm geliştiriciler doğrudan sorgu yazmaya alışkın değil ve kodun içine sorgular karıştığında yeniden düzenleme/anlama çok zorlaşabiliyor. Sonunda SQL'in de bir kütüphane olarak soyutlanacağı söyleniyor

    • Django ORM'yi uzun süre kullanmış ve gerçekten mükemmel bir yazılım olduğunu düşünmüş, ancak son dönemde sqlc kullanınca sorguları doğrudan Go koduna dönüştüren yaklaşımın ORM ile raw SQL arasında daha ideal bir uzlaşma noktası olduğu fikrine varmış

    • Sadece gerçekten iyi bir ORM (ör. Entity Framework Core) deneyimi yaşamamış olabileceğinizi söyleyen bir görüş

  • Başlığın aslında gerçekten sunum başlığına uygun olarak "Scaling PostgreSQL to the Next Level at OpenAI" olması gerektiğine dair hafif bir yorum
 
ddogi 2025-05-25

Görünüşe göre Oracle RAC ya da DB2 pureScale gibi çoklu write destekli ticari ürünler değerlendirme kapsamına alınmamış.