pg_graphql ile Hasura ve PostGraphile, Postgres üzerinde

pg_graphql SQL şemanızı inceler ve Geçiş kurallarına uygun bir GraphQL şeması oluşturur — <table>Collection, edges, node, sütun türüne göre filtreler, imlece göre sayfalandırma. Elle yazılacak veya bakımı yapılacak SDL yok: GraphQL şeması Postgres şemanızı takip eder.

Mimari açısından önemli olan nokta şu; bu şema üreteci veritabanının içinde bir SQL fonksiyonu olarak yaşıyor, yanında bir HTTP prosesi olarak değil. Aurabase, uzantının 1.6.1 sürümünü (7 Mayıs 2026'da yayınlandı) Postgres görüntüsüne — Supabase tarafından dağıtılan resmi .deb paketine sabitler. Hem paylaşılan kümeye hem de özel Postgres örneklerine yüklenir.

pg_graphql'nin uzun süredir yerel olarak etkinleştirildiği Supabase'den geliyorsanız, mantık size tanıdık gelecektir. Ayrıntılı karşılaştırmamız ve geçiş kılavuzumuz aynı kalan RLS şemasının ve ilkelerinin geri kalanını kapsar.

"Postgres'te anlık GraphQL"in iki tarihi rakibinden hiçbiri ortadan kaybolmadı. Konumları değişti ve güncellenmiş bir makale, iki yıl önceki duruma atıfta bulunmak yerine bunu yansıtmalıdır.

Hasura, Haziran 2025'te kurucu ortağı Tanmai Gopal tarafından imzalanan "GraphQL'den PromptQL'e: Yeni Bir Bölüm Başlıyor" başlıklı açık bir gönderi yayınladı. Mesaj: Şirket, yol haritasını AI aracıları için tasarlanmış bir veri erişim katmanı olan PromptQLüzerine yeniden odaklıyor. GraphQL motoru kaldırılmadı - Hasura'nın ana sayfası onu hâlâ "savaşta test edilmiş" olarak sunuyor - ancak artık öncelikli mesaj değil.

PostGraphileise tam tersini yaptı. 2023'ten beri beta olarak geliştirilmekte olan 5. sürümü, Grafast adı verilen yeni bir sorgu planlama motoruyla 24 Mart 2026'da genel kullanıma sunuldu. Bu, gücü tükenen bir proje değil: son sürüm olan 5.1.4, 5 Ağustos 2026 tarihlidir. npm paketi yalnızca 16 - 22 Ağustos 2026 haftasında 119.230 indirme saydı (npm kaydı, 23 Ağustos 2026'ya danışıldı).

Diğer her şeyi (işletme maliyeti, saldırı yüzeyi, gecikme) yapılandıran fark, GraphQL motorunun çalıştığı yerdir.

Dürüst olmak gerekirse: PostGraphile ayrıca Postgres'e pgSettings ve rol değiştirme aracılığıyla yetkilendirme yetkisi verir; yerel RLS, pg_graphql'ye özel değildir. Farklı olan şey, bu köprüyü kimin barındırdığı ve yapılandırdığıdır: PostGraphile'da sizsiniz; Aurabase'de bu zaten yapıldı.

Etkinleştirme proje başına isteğe bağlıdır ve Postgres motor projeleri için ayrılmıştır - bir MongoDB projesi isteği reddeder (GRAPHQL_UNSUPPORTED_ENGINE), pg_graphql diğer motorda eşdeğeri olmayan bir Postgres uzantısıdır.

CLI aracılığıyla veya doğrudan yönetim planını çağırarak:

# Idempotent: Halihazırda etkinleştirilmiş bir projeyi geri çağırmak hiçbir şeyi yeniden yaratmaz
aura projects graphql-enable <project_id>

# HTTP eşdeğeri (yönetim düzlemi, JWT konsolu)
curl -X POST "$AURA_CONTROL_URL/v1/control/projects/$PROJECT_ID/graphql/enable" \
  -H "Authorization: Bearer $CONSOLE_JWT"

Sunucu tarafında çağrı, provizörün tek bir işlemde yürüttüğü bir graphql_enable işini yürütür: uzantının yüklenmesi, şemanızda graphql() işlevinin oluşturulması, uygulama rollerine GRANT'lar. Bir adım başarısız olursa her şey iptal edilir; sarmalayıcı asla yarıya kadar kurulmaz ve graphql_enabled yalnızca tam başarıdan sonra true'ye geçer.

Hem paylaşılan Postgres kümesinde hem de proje başına özel bir CNPG örneğinde çalışır; iki farklı Postgres görüntüsü, ancak aynı uzantı mekanizması. Tahsis edilmiş örneklerde, uzantı, doğrudan SQL yerine CNPG operatörünün bildirimsel bildirimi aracılığıyla yüklenir; bu yakın zamanda yapılan bir düzeltmedir. Özel bir küme, uygulama süper kullanıcı erişimi olmadan çalışır ve pg_graphql, CREATE EXTENSIONiçin tam olarak bu ayrıcalığa ihtiyaç duyar.

Studio'da aynı akış Tablo Yapılandırması sekmesinden geçer. Buradaki bir düğme, uzantıyı proje düzeyinde etkinleştirir - yukarıdakiyle aynı HTTP çağrısı, yakınsamaya kadar yoklama ile. Daha sonra ikinci bir kontrol, editörden ayrılmadan totalCount ve GraphQL koleksiyonundaki toplama alanlarını etkinleştirmek veya devre dışı bırakmak için tablo başına bir @graphql yönergesi ayarlar.

Tek komut görünümü: etkinleştirme → iş parçacıklı provizyon (idempotent, zaten uçuştaysa işlem yok) → DDL işlemi (uzantı, sarmalayıcı işlevi, GRANT'lar) → graphql_enabled işaretini yalnızca tam başarıdan sonra ayarlayın → istekler /rpc/graphqlaracılığıyla mümkündür.

Aurabase tarafından ayarlanan işlev SECURITY INVOKER'dir — Postgres'in varsayılan davranışı, gelecekteki bir yeniden düzenlemenin bunu kazara değiştirmemesi için açıklanmıştır. Gerçek arayanın ayrıcalıklarıyla çalışır (aura_anon, aura_authenticated veya aura_service_role, JWT talebine bağlı olarak), dolayısıyla RLS politikalarınız tam olarak REST isteğinde olduğu gibi uygulanır.

Hasura'da mimari yapı itibarıyla farklıdır: motor, her GraphQL sorgusunu Hasura'ya özgü izin kurallarıyla kısıtlanan bir SQL sorgusuna dönüştürür. Bu kurallar, Postgres RLS'ye bir delegasyon değil, paralel bir sistem olan kendi katmanındaki rol ve tablo başına tanımlanır. Erişim kurallarını denetlemek için tek bir yer yerine iki yer.

İçgözlem ({ __schema { ... } }), her Aurabase projesinde varsayılan olarak devre dışı kalır; bu, platformun geri kalanıyla tutarlı bir duruştur. Apollo Studio veya graphql-codegen gibi bir aracın ihtiyacı varsa COMMENT ON SCHEMA aracılığıyla şema ile etkinleştirilebilir.

graphql_enabled ile truearası bir kez olduğunda, ağ geçidinde özel bir /graphql rotası görünmez. İstek, tıpkı SDK'dan çağrılan herhangi bir Postgres işlevi gibi, genel RPC proxy'siüzerinden gider.

curl -X POST "$AURA_URL/v1/db/$PROJECT_ID/rpc/graphql" \
  -H "apikey: $AURA_ANON_KEY" -H "Authorization: Bearer $JWT" \
  -H "Content-Type: application/json" \
  -d '{"query":"query { postsCollection(first: 10, filter: { published: { eq: true } }) { edges { node { id title created_at } } } }"}'

Yanıt, ek Aurabase sarmalama olmadan GraphQL spesifikasyonunu ({ data, errors }) takip eder: ağ geçidi, hedeflenen RPC'nin graphql olduğunu algılar ve sıradan bir RPC'nin aksine onu yeniden sarmaz. Standart bir GraphQL istemcisi (Apollo, urql, graphql-request) çıktıyı olduğu gibi tüketir.

Diyagramdaki bir @graphql yönergesi aracılığıyla etkinleştirme sonrasında varsayılan olarak iki ayar ayarlanır: max_rows: 1000 ve inflect_names: true. pg_graphql varsayılan olarak koleksiyon başına 10.000 satırla sınırlanır — first:olmadan büyük bir tablo belleği doyurabilir. inflect_names, SQL tablolarının ham yılan_durumu yerine okunabilir tür adlarını verir.

Bu blogun ruhuna uygun olarak, saklanmak yerine belgelenmek.

• Yerel GraphQL aboneliği yok. pg_graphql, gerçek zamanlı değil, sorguları ve mutasyonları kapsar subscriptions — bu, Aurabase'in ihmali değil, uzantının kendi sınırlamasıdır. Gerçek zamanlı Aurabase mevcuttur, ancak GraphQL abonelik köprüsü değil, ayrı bir kanal (postgres_changes) aracılığıyla.
• Hasura'da bildirime dayalı işlem yok. "GraphQL mutasyonuna bağlı iş web kancası" modelinin doğrudan bir eşdeğeri yoktur; Aurabase'de bu mantık, özel bir GraphQL yapılandırması aracılığıyla değil, bir Postgres işlevi veya bir Edge İşlevi aracılığıyla gider.
• Postgres motoru için ayrılmıştır. Bir MongoDB projesi bunu etkinleştiremez; herhangi bir geçici çözüm amaçlanmamıştır.

Her üç seçenek de meşrudur; doğru seçim, halihazırda sahip olduğunuz şeye ve neyden kaçınmak istediğinize bağlıdır.

• Aurabase'de pg_graphql — RLS veritabanınız ve politikalarınız zaten Aurabase'de yayınlanıyorsa ve izlenecek ek hizmetler olmadan onu sorgulamanın ikinci bir yolunu istiyorsanız.
• Hasura — birden fazla veri kaynağını (yalnızca Postgres'i değil) tek bir GraphQL şeması arkasında birleştirirseniz veya PromptQL ve yapay zeka aracısı yaklaşımı yol haritanıza uyuyorsa.
• PostGraphile v5 — eklenti sistemi aracılığıyla oluşturulan şema üzerinde hassas kontrol istiyorsanız ve onu entegre edebileceğiniz bir Node.js sunucusunu zaten çalıştırıyorsanız.

Tam sorgu söz dizimi için — sütun türüne göre filtreler, orderBysıralama, imlece göre sayfalandırma, insertInto<Table>Collection mutasyonlar — resmi pg_graphqlbelgelerine bakın. Aşağıdaki Aurabase GraphQL belgeleri de tüm döngünün ayrıntılarını vermektedir.