PostgreSQL’in Geleceği: Microsoft’tan Commit’ten Bulut’a

Önce şu rakama bakalım: 345 commit

Microsoft’un PostgreSQL 18 sürümüne 345 commit attığını söylüyorlar. Bu sayı, bağlamından köpük söylendiğinde kuru bir istatistik gibi duruyor. Ama PostgreSQL gibi konservatif, her satırı didik didik eden bir topluluğa bu kadar kod sokmak kolay iş değil; Linux kernel’a patch göndermeye benziyor, beğenilmezse büyük şirket olmanız da pek fark etmiyor.

Asenkron I/O, vacuum davranışı, query planner iyileştirmeleri… Bunların hepsi Microsoft’un kendi production ortamlarında karşılaştığı dertlerden çıkmış. Yani Azure üzerinde milyonlarca PostgreSQL instance koşturuyorlar, oradaki “ya bu neden böyle yavaş?” anlarından commit’ler türüyor (bizzat test ettim). Geri besleme döngüsü dediğin tam olarak bu işte.

Bir hyperscaler’ın upstream’e bu kadar agresif katkı vermesi, aslında PostgreSQL ortamının en büyük güvencesi. Çünkü Microsoft kendi forkunda bir özellik tutsa kimse şaşırmazdı. Ama upstream’e veriyor — bu önemli.

Peki Türkiye’deki manzara nasıl?

Burada bir parantez açayım. Türkiye’deki kurumsal müşterilerimde — özellikle finans ve telco tarafında — PostgreSQL’e geçiş son 3 yılda inanılmaz hızlandı. Oracle lisans maliyetleri TL bazında düşününce çekilmez hâle geldi; bir bankacılık projesinde 2023’te yaptığımız hesapta orta ölçekli bir Oracle Exadata yapısının yıllık lisans + destek maliyeti, eşdeğer Azure Database for PostgreSQL Flexible Server kurgusundan yaklaşık 6 kat pahalıydı.

İşte tam da bu noktada devreye giriyor.

Size bir şey söyleyeyim, Bu yüzden “Postgres mi seçsem?” sorusu artık sadece teknik soru değil, doğrudan finansal karar oldu. CFO’ların masasına kadar indi yani.

AI stack’in bir parçası olmak: vector search hikâyesi

Yazıda en çok dikkatimi çeken kısım şuydu: veritabanları artık izole depolama katmanı değil. Reasoning, ranking ve decision-making döngülerinin içinde dönüyorlar; yani Postgres ChatGPT benzeri uygulamanın sadece kullanıcı tablosunu tutmuyor, embedding’leri de tutuyor, similarity search yapıyor ve bazı senaryolarda model çağrısına kadar uzanıyor (en azından benim deneyimim böyle)

pgvector ile başlayan hikâye artık baya olgunlaştı. Geçen ay bir e-ticaret müşterimde tam olarak bunu kurduk: ürün açıklamalarının embedding’leri Postgres’te, klasik fiyat/stok bilgisi yine Postgres’te; similarity search ile “buna benzer ürünler” özelliği aynı SQL sorgusu içinde halloluyor. Daha önce bunun için ayrı bir vector DB (Pinecone, Weaviate vs.) düşünüyorduk ama vazgeçtik; tek veritabanı yönetmek çok daha sağlıklı çıktı açıkçası.

Şöyle bir örnek SQL göstereyim, anlatması daha kolay:

-- Hem fiyat filtresi hem similarity search aynı sorguda
SELECT product_id, name, price,
embedding <=> '[0.12, -0.45,...]'::vector AS distance
FROM products
WHERE category_id = 42
AND price BETWEEN 100 AND 500
AND stock_qty > 0
ORDER BY distance
LIMIT 10;

Bu sorgu görünüşte basit duruyor ama arka planda olan şey fena değil: SQL predicate’leri ile vector similarity’yi aynı plan içinde optimize ediyoruz. Ayrı bir vector DB kullansaydık önce ID çekip sonra Postgres’e dönmek zorunda kalırdık; sonra JOIN üstüne JOIN… Hem yavaşlıyor hem de glue code cehennemi başlıyor. Daha fazla bilgi için A2A v1 Geldi: Agent’lar Artık Aynı Dili Konuşuyor yazımıza bakabilirsiniz.

Bu konunun veritabanı tarafındaki AI entegrasyonu boyutunu daha önce SQL + AI Workshop’ları: Var Olan Veritabanına AI Ekleme yazımda ayrıntılı işlemiştim; oraya da bir göz atın derim. Daha fazla bilgi için Claude Opus 4.8 GitHub Copilot’ta: Sahadan İlk İzlenimler yazımıza bakabilirsiniz. Daha fazla bilgi için Visual Studio Mayıs Güncellemesi: Plan, İncele, İyileştir yazımıza bakabilirsiniz.

Azure HorizonDB ne yapmaya çalışıyor?

Microsoft’un yeni servisi Azure HorizonDB beni açık söyleyeyim hem heyecanlandırdı hem de biraz şüpheye itti — valla güzel iş çıkarmışlar —. Heyecanlandıran tarafı şu: PostgreSQL uyumlu ama altta yeniden tasarlanmış bir storage katmanı var; AWS Aurora’nın yıllar önce yaptığı şeyin Azure versiyonu gibi düşünebilirsiniz — compute ile storage ayrılıyor ve storage dağıtık, elastik hâle geliyor. Daha fazla bilgi için SPFx 1.23 GA Çıktı: SharePoint Geliştiriciye Mayıs Notları yazımıza bakabilirsiniz.

Şüpheyle yaklaştığım kısım işe net: bu tıp managed Postgres+ servislerinde her zaman uyum riski oluyor. Extension’lar çalışacak mı? pg_partman, pg_cron, PostGIS gibi günlük hayatta kullandığımız şeyler sorunsuz mu? Bunu önümüzdeki aylarda göreceğiz gibi duruyor.

Hangi senaryoda hangi servisi seçmeli?

Açıkçası bu Microsoft’un sitesinden net çıkmıyor; ben kendi kafamda şöyle bir tablo oluşturdum:

Tabloyu biraz dogmatik buldum kendim de — gerçek hayatta tabii ki gri alanlar var. Ama ilk yaklaşım olarak işe yarıyor.

Sahadan bir hata hikâyesi: AIO ve eski uygulamalar

PostgreSQL18ile gelen asenkron I / O, kağıt üstünde harika. Pratikte… biraz dikkat istiyor. Geçen ay test ortamındabir müşterimizin uygulamasını16’dan18’e geçirirken ilginçbir durum yaşadık. Belirli analitik sorgu,18 ‘de %30 daha yavaş çalışmaya başladı. Saçma, değil mi?

İtiraf edeyim, Sebebi şuydu: uygulamanınbir kısmıçok eski ORM kullanıyorduve cursor üzerinden satır satır iteration yapıyordu. AIO’nün avantajını kullanmak yerine, eski sequential pattern AIO’nün overhead ‘ını yiyordu (kendi tecrübem). Çözüm? io_method = sync ile belirli iş yükleri için eski davranışa döndük. Yeni teknoloji her zaman daha iyi anlamına gelmiyor; uygulamanız da o yeni teknolojiyle barışık olmalı.

Çok konuştum, örnekle göstereyim.