PostgREST: Veritabanının şemasından hazır REST API

Aynı kodu tekrar tekrar yazmak

Bir web uygulaması için API yazdığını düşün. Veritabanında todos diye bir tablon var. Onu listelemek, eklemek, güncellemek ve silmek için route’lar yazıyorsun. Gelen veriyi doğruluyorsun. Bir ORM ile sorgu kuruyorsun. Kullanıcının sadece kendi kayıtlarını görmesi için bir yetki kontrolü ekliyorsun. Sonra tabloya yeni bir sütun ekleyince bu katmanların hepsini tek tek güncelliyorsun.

PostgREST bu ara katmanı tamamen kaldırmayı öneriyor. Haskell ile yazılmış, MIT lisanslı açık kaynak bir sunucu. Bir Postgres veritabanına bağlanıyor, şemayı okuyor ve her tabloyu, her view’ı otomatik olarak bir HTTP adresine çeviriyor.

Nasıl görünüyor?

todos tablosu varsa /todos adresi de var. Gerisi URL’de:

• GET /todos?completed=eq.false tamamlanmamış işleri getiriyor.
• GET /todos?order=created_at.desc&limit=10 son on kaydı sıralıyor.
• GET /todos?select=title,users(name) yabancı anahtar (foreign key) üzerinden ilişkili tabloyu da tek istekte getiriyor.
• POST /todos gövdedeki JSON’u yeni satır olarak ekliyor.

Daha karmaşık bir iş için bir SQL fonksiyonu yazıyorsun, o da /rpc/ altında bir adres oluyor. PostgREST ayrıca API’nin OpenAPI tanımını kendisi üretiyor. Swagger UI gibi bir araçla tarayıcıda gezilebilir, denenebilir belgeler hazır geliyor.

Videoda kurulum üç konteynerlik bir Docker Compose dosyası: Postgres, PostgREST ve belgeler için Swagger UI. Videoya göre sıfırdan çalışan, filtreli ve sayfalı bir API’ye bir dakika içinde ulaşılıyor.

Güvenlik veritabanında

Burası işin asıl fikri. PostgREST’in kendi belgesi rolünü şöyle tanımlıyor: Kim olduğunu doğrulamak (authentication) PostgREST’in işi, ne yapabileceğine karar vermek (authorization) veritabanının.

1. İstemci isteğe bir JWT (imzalı bir kimlik belgesi) ekliyor. İçinde bir role alanı var.
2. PostgREST imzayı doğruluyor ve o istek boyunca veritabanına o rolle bağlanıyor (SET LOCAL ROLE). JWT yoksa ayarlarda tanımlı anonim role geçiyor.
3. Hangi rolün hangi tabloya erişebileceği Postgres’in kendi GRANT izinleriyle belirleniyor.
4. Satır düzeyinde ise Row Level Security (RLS) devreye giriyor. Örneğin “kullanıcı sadece kendi gönderdiği ya da kendisine gelen mesajları görür” kuralını tabloya bir POLICY olarak yazıyorsun.

Sonuç: Yetki kuralları uygulama kodunun farklı köşelerine dağılmıyor, tek bir yerde duruyor. Başka bir araç aynı veritabanına bağlansa bile kurallar onu da bağlıyor.

Kim kullanıyor?

En bilinen örnek Supabase. Belgelerine göre Supabase’in REST API’si PostgREST üzerine kurulu. Supabase’te tablolara RLS yazmanın bu kadar önemli olmasının sebebi de bu. Proje GitHub’da 27 binin üzerinde yıldıza sahip, Eylül 2026’da 16.4 sürümü çıktı ve hâlâ aktif geliştiriliyor.

Bedeli ne?

Videonun da altını çizdiği gibi her şeyi çözmüyor:

• RLS’yi doğru yazmak zor. Bir kuralı unutursan veri açıkta kalabilir. Ağır RLS kuralları sorguları yavaşlatabilir. Kuralları ve indeksleri dikkatle tasarlamak gerekiyor. Supabase’te açık anahtarın neden ancak RLS ile güvende olduğunu Supabase anahtarları yazımızda anlattık.
• İş mantığı SQL’e kayıyor. Karmaşık işlemler view’lara, fonksiyonlara ve trigger’lara gidiyor. Bunu seven de var, sevmeyen de. Ekipte SQL bilgisi yoksa bakım zorlaşır.
• Her şey veritabanı değil. Ödeme sağlayıcısına istek atmak ya da e-posta göndermek gibi işler için yine ince bir backend katmanı gerekebilir.

Prototipler, iç araçlar ve verinin merkezde olduğu uygulamalar için iyi bir başlangıç. Postgres’in başka hangi işleri üstlenebildiğini her şey için Postgres yazımızda anlattık.

Düşün

• Son yazdığın API’de kodun ne kadarı sadece veriyi veritabanından alıp JSON’a çeviriyordu?
• Yetki kurallarını uygulama kodunda mı, veritabanında mı tutmak sana daha güvenli geliyor? Neden?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.