PostgREST: üretimde referans ve gerçek sınırlar

PostgREST'teki bir HTTP çıktı testi esas olarak Postgres'i ölçer, nadiren PostgREST'i ölçer. Sunucu, tabanın önünde ince bir çeviri katmanıdır. Gerçek dünyadaki yüklerin büyük çoğunluğunda yanıt süresine, onu oluşturan süreç değil, yürütülen SQL sorgusu hakimdir.

PostgREST projesi, GitHub üzerinde bu konu için özel bir depo tutar: PostgREST/postgrest-benchmark; bu, yalıtılmış bir pazarlama rakamı yayınlamak yerine sürümden sürüme üretim değişimlerini izler. Burada ne gerçekleştirdik ne de yeniden yayınladık. Sonuçları, donanıma, şematik boyuta ve test edilen senaryoya, yani kendi kıyaslama protokolümüzün bir rakamı belirtmeden önce belgelenmesini gerektirdiği değişkenlere bağlıdır.

PostgREST'in altında, gerçekten önemli olan katmanı ölçen pgbench bulunur: Eş zamanlı yük altında SQL işlem süresi. Bu, resmi PostgreSQL kıyaslama aracıdır (postgresql.org/docs/current/pgbench.html, 24 Ağustos 2026'da erişildi). Bu protokolü burada tekrarlamak yerine, bu makale PostgREST'in üretimdeki dört somut mimari sınırlamasını belgeliyor; bunların her biri Aurabase kaynak kodunda veya resmi proje belgelerinde doğrulanıyor.

Her Aurabase Postgres motoru projesi, kümesiyle aynı konumda bulunan iki özel PostgREST kopyası alır. Bunları dağıtan Kubernetes manifestosu mütevazı kaynaklar belirler.

Bu kopyaların gerçekte tükettiği şey CPU değildir: bunlar Postgres birinciline olan bağlantılardır. Her PostgREST örneği, kiracı için dağıtılan PgBouncer havuzlayıcısından geçmeden doğrudan birincil sunucuya (-rw) bağlanır. Bu seçim, PostgREST uyumluluğuhakkındaki makalemizde zaten ayrıntılı olarak açıklanmıştır: LISTEN/NOTIFY şema yeniden yükleme mekanizması, işlem modundaki bir havuz oluşturucuyla uyumlu olmayan kalıcı bir bağlantı gerektirir. Bu makale şunu ekliyor: Bağlantılar açısından gerçekte maliyeti ne kadar ve zirveye ulaştığı yerler.

Bu havuzun kopya başına boyutu (PGRST_DB_POOL), her proje için PostgREST bildirimini oluşturan k8s_tenant.rsişlevinde doğrulanan proje düzeyine bağlı olarak kasıtlı olarak farklılık gösterir:

# Birincildeki kopya başına bağlantıların parmak izi.
env:
  - { name: PGRST_DB_POOL, value: "PGRST_DB_POOL_VALUE" }  # 10 (özel) veya 2 (paylaşılan)

Tahsis edilmiş düzeyde kısıtlama gevşetilmiştir: Bir projenin kendi CNPG kümesi vardır, dolayısıyla kendi max_connectionsve yedek komşuları yoktur. Paylaşılan düzeyde, aynı kuruluştan çeşitli projeler tek bir kümeyi paylaşır: aşağıdaki bölümde geliştirilen bağlantı bütçesini belirleyici kılan bu bağlamdır.

Paylaşılan bir Postgres kümesinde, aynı anda etkin olan projelerin sayısını sınırlayan şey HTTP verimi değildir. Bu, mevcut max_connectionsile karşılaştırıldığında PostgREST örneklerinin birincilde açık tuttuğu bağlantıların sayısıdır.

Aurabase bu bütçeyi doğrudan fleet.rs: (max_connections − réserve superuser/CNPG − connexions réservées au pooler) ÷ connexions par projet éveilléolarak işaretlenen gerçek küme sınırlarından, 1. kattan alır. Sabit rezerv 10 bağlantıdır (süper kullanıcı, CNPG bulut sunucusu yöneticisi, ölçüm aktarıcısı, hazırlayıcı yönetici marjı). Teslim edilen kusurlara göre (çoğaltma başına 2 havuz, 2 kopya veya uyandırılan proje başına 4 bağlantı), hesaplama, kümenin boyutlandırma düzeyine bağlı olarak üç farklı bütçe verir.

Kaynak: fleet.rs::derive_wake_budget ve wake_budget_for_org_planAurabase kodundan türetilmiştir, 24 Ağustos 2026'da yeniden okunmuştur.

Bu bütçe, sahip olunan projelerin kotası değildir: bir team kuruluşu, çoğu atıl durumda olan 50 projeye sahip olabilir. Bu bir eşzamanlılık sınırıdır: birincilde aynı anda açık bağlantıları tutabilen projelerin sayısı. Bütçenin aşılmasıyla uyanma başarısız olmaz; kardeş bir proje aynı dosyada kontrol edilerek uyku durumuna dönene kadar ertelenir. max_connections boyutlandırma konusu, max_connectionsayarı ve tahsis edilmiş ve paylaşımlı taban'de bir bütün olarak tahsis edilmiş/karşılıklılaştırılmış değiş tokuş hakkındaki makalemizde genişletilmiştir.

Tam bir toplam istemek, Postgres'i her sorguda filtrelenen sonucun görünür satırlarını saymaya zorlar; bu, ücretsiz bir işlem değil, tabloyla birlikte artan bir maliyettir.

PostgreSQL, herhangi bir indekslenmiş satır sayacını kullanıma hazır tutmaz. MVCC'de bir satırın görünürlüğü onu okuyan işleme bağlıdır. Bu nedenle tam bir COUNT(*) önceden hesaplanmış bir değeri okumak yerine aday satırları ziyaret etmelidir. Bu, kendi yaklaşık sayaçlarını Postgres işlem davranışıyla karşılaştıran ClickHouse gibi analiz sağlayıcıları da dahil olmak üzere Postgres ekosisteminde iyi belgelenmiş bir yapısal sınırlamadır.

# Büyük bir tabloda pahalıdır: filtrelenen sonucun MVCC taramasını zorlar
curl "https://<gateway>/v1/db/<project_id>/orders?status=eq.paid" \
  -H "apikey: <clé>" -H "Prefer: count=exact"

# PostgREST tarafından belgelenen daha ucuz alternatifler
  -H "Prefer: count=planned"   # planlayıcı aracılığıyla tahmin
  -H "Prefer: count=estimated" # bir eşiğin ötesinde planlanmış, tam altında

PostgREST bu üç sayma stratejisini yerel olarak belgelemektedir (postgrest.org, 24 Ağustos 2026'da erişilmiştir). exact stratejisi, tarama fiyatı üzerinden bir toplamı garanti eder. planned sorgu planlayıcıdan neredeyse ücretsiz bir tahmin döndürür. estimated bir eşiğe bağlı olarak ikisi arasında otomatik olarak geçiş yapar. Seçim kozmetik değildir: Birkaç milyon satırdan oluşan bir tabloda count=exact gerektiren bir sayfalandırma, kullanıcı sonuncuya hiç başvurmasa bile her sayfada bu taramanın bedelini öder.

Satır sınırı, açıkça kesin bir toplam talep edilmediği sürece, gövdede veya başlıklarda herhangi bir belirti olmadan PostgREST yanıtını kesebilir. Bunu varsayılan değil, özel bir Aurabase örneğinde gerçek koşullarda ölçtük.

PGRST_DB_MAX_ROWS=5içeren 10 satırlık bir test tablosunda PostgREST v12.2.3, iki farklı durum için tam olarak aynı Content-Range başlığını işler:

count=exactolmadan, 5 satırın yanıtı, gerçekte yalnızca 5 içeren bir tablodan ayırt edilemez: Content-Range: 0-4/*, hiçbir zaman sınır uygulanmadan, oluşturulan satırları açıklar. Bu durumda, doğrudan Aurabase SDK'nın PostgREST yolunda ölçülen gerçek sınır, hiçbir yerde görünmez.

PostgREST, Postgres şemasını başlangıçta bellekte tutar. Bir DDL'den (tablo oluştur, sütun ekle) sonra, yeni rota yanıt vermeden önce bu önbelleğin yeniden yüklenmesi gerekir ve bu yeniden yükleme eşzamansızdır.

Bu pencereye gelen bir yazma işlemi, tablo Postgres tarafında mevcut olsa bile geçici bir 404 (önbellek henüz güncel değil) alabilir. Aurabase ağ geçidi bunu, postgrest_proxy.rsile doğrulanan sınırlı bir yeniden deneme döngüsüyle karşılar: 8 denemeye kadar, artan geri çekilme (250 ms artı deneme başına 100 ms), en kötü durumda kümülatif 3,5 saniye. Bu mekanizma yalnızca yazma işlemlerini etkiler, asla okumayı etkilemez.

Şirket içinde barındırılan PostgREST dağıtımı için ders genelleştirilir. Uygulamanızdaki her DDL yolu, işleme NOTIFY veya bir SIGUSR1 sinyali aracılığıyla yeniden yüklemeyi tetiklemelidir. Aksi takdirde, bir geçiş, dağıtımdan hemen sonra aralıklı hatalar olarak gizlenen bir p99 gecikme artışına neden olur.

Burada belgelenen dört sınırlamanın ortak bir yanı vardır: hiçbiri yalıtılmış bir HTTP üretim testinde görülmez, ancak dördü de PostgREST dağıtımının üretime ölçeklenip ölçeklenmeyeceğini belirler.

• Bağlantı bütçesi: kiracı başına aktarım hızına bakılmaksızın, paylaşılan bir kümede aynı anda etkin olan kiracıların sayısını sınırlar.
• Kesin COUNT maliyeti: yüke göre değil tabloya göre artar; planned/estimatedile atlanır.
• Sessiz kesme: doğru şekilde yapılandırılmış bir satır sınırı, yetersiz şekilde düzenlenmiş sayfalamayı yine de bozabilir.
• Şema yeniden yükleme: her geçişten sonra bir gecikme penceresi; yeniden yükleme sinyali iyi bağlanmışsa sınırlanır, aksi halde sınırsızdır.

İster şirket içinde barındırılan PostgREST, ister Hasura tarzı bir GraphQL katmanı veya özel bir API arasında seçim yapıyor olun, bu dört eksen, yalıtılmış bir istek/s rakamından daha iyi bir karşılaştırma noktasıdır. Karşılaştırmamıza bakın PostgREST vs Hasura vs özel API. Veritabanınızın önünde duran havuzlayıcının seçimi de aynı derecede önemlidir: karşılaştırmamız PgBouncer vs Supavisor vs PgCat PostgREST'in neden işlem modunda bir havuzlayıcıdan geçemediğini ayrıntılarıyla anlatır.

PostgREST tek başına HTTP yükü altında neredeyse hiçbir zaman bozulmaz: mimarisi bunun için çok basittir. Üretimde kesintiye uğrayan şey, onu çevreleyen şeydir: kopyalarının kaç bağlantıyı açık tuttuğu, toplam maliyetin tam olarak ne kadar olduğu. Bu aynı zamanda bir kesmenin görünür kalıp kalmayacağını ve geçişten sonra pencerenin ne kadar süreceğini de içerir.

Bu dört sınırlama Aurabase'e özel değildir: Kendi kendine barındırılan veya yönetilen tüm PostgREST dağıtımları için geçerlidir. Bu kodun gösterdiği şey, çok kiracılı dağıtımın bunları üretimde şaşırtıcı bırakmak yerine nasıl açık hale getirdiğidir.