Data Dünyasında Geçen Hafta (10-16 Ağustos 2026): Databricks, PGlite, PostgreSQL, MongoDB

This post is published in Turkish. An English version is not available yet. Read it in Turkish →

Merhaba,

10-16 Ağustos haftası, dışarıdan bakınca birbiriyle alakasız beş ayrı haberle geçti: dev bir yatırım turunun kapanışı, küçük bir açık kaynak şirketinin satın alınması, sıradan görünen bir güvenlik yaması, bir veritabanı konferansındaki ürün duyuruları ve bir katalog projesinin yeni sürümü. Ayrı şirketler, ayrı kategoriler.

Ama bu hafta işin güzel tarafı şu: haberleri birbirine bağlamak için zorlamanıza gerek yok, hepsi zaten aynı cümleyi kuruyor. Bu yazıda esas anlatmak istediğim de o cümle. Önce haberleri tek tek geçeceğim, sonra hepsini aynı yere bağlayacağım.

Baştan söyleyeyim, tezim şu: veritabanı katmanı artık insan geliştirici için değil, yapay zeka ajanı için yeniden yazılıyor. Bu haftanın beş haberinin dördü doğrudan bunun sonucu, beşincisi ise bu hızın altında kaybolmaması gereken bir hatırlatma.

Haftanın özeti: tek tabloda

Tarih	Olay	Durum	Neden önemli
11 Ağu	Databricks × Electric (PGlite)	Satın alma duyurusu	Her ajana kendi tek kullanımlık Postgres’i fikri satın alınıyor
13 Ağu	Databricks 190 milyar $	Tur kapandı	Temmuz’daki 188 milyarlık term sheet 190’a kapandı; para ajan altyapısına gidiyor
13 Ağu	PostgreSQL güvenlik dalgası + 19 Beta 3	Yama yayında / Beta	Tek seferde rekor 28 CVE; sıkıcı disiplin hala hükmediyor
13 Ağu	MongoDB Build Fest	GA	Otomatik gömme, yeniden sıralama ve yönetilen MCP sunucusu motorun içine giriyor
2-12 Ağu*	Apache Polaris 1.7.0 + CVE	Sürüm + güvenlik	Lakehouse katalogları da yönetişim/güvenlik tarafında olgunlaşıyor

* Polaris 1.7.0 duyurusu 2 Ağustos’a, yani seçtiğim pencerenin hemen öncesine ait; ilgili CVE açıklaması ve tartışma haftanın içine düştüğü için tabloya aldım. Tarihi yazının içinde ayrıca belirtiyorum.

1. Databricks, Electric’i aldı: her ajana kendi tek kullanımlık Postgres’i

Bu haftanın en az manşet olan ama tezi en net kuran haberi bu. Databricks, 11 Ağustos’ta Electric adlı şirketi satın aldığını duyurdu. Electric’in iki işi var: PGlite ve bir senkronizasyon motoru. Anlaşma bedeli açıklanmadı.

PGlite’ın ne olduğunu anlamak, haberin neden önemli olduğunu anlamak demek. PGlite, WebAssembly’ye (WASM) derlenmiş tam bir PostgreSQL veritabanı. Yani bir tarayıcı sekmesinin, bir Node.js sürecinin ya da bir ajanın kod çalıştırdığı sandbox’ın içinde, uzaktaki bir sunucuya tek bir ağ çağrısı yapmadan çalışabilen gerçek bir Postgres. Şirketin verdiği rakama göre PGlite son on iki ayda haftalık 1 milyon indirmeden 13 milyon indirmeye çıkmış. Bu büyümeyi süren şey de tam olarak konumuz: uzaktaki bir veritabanına gitmeden yerel duruma ihtiyaç duyan, ajan-yerel (agent-native) uygulamalar.

Electric ekibi, Databricks’in geçen yıl yaklaşık 1 milyar dolara satın aldığı Neon‘un altına katılıyor. Neon, Databricks’in “AI ajanları için sunucusuz Postgres” hizmeti olan Lakebase‘in temeli. Databricks’in Neon’u alırken paylaştığı çarpıcı veri şuydu: Neon üzerinde açılan veritabanlarının %80’inden fazlası insan değil, ajan tarafından otomatik oluşturuluyordu. Yani bu satın alma tek başına bir haber değil, bir stratejinin ikinci hamlesi.

Neden-sonuç kısmı: Databricks’in kurduğu modeli sade haliyle anlatayım. Klasik mimaride bir uygulama tek bir merkezi veritabanına konuşur. Ajan dünyasında ise resim tersine dönüyor: her ajan, kendi işini yapması için PGlite ile kendi yerel Postgres’ini çalıştırıyor, sonra durumunu senkronizasyon motoruyla merkezi bir Lakebase Postgres’e geri yazıyor. Yani “bir uygulama, bir veritabanı” yerine “binlerce ajan, binlerce küçük ve tek kullanımlık veritabanı ve onları bir arada tutan bir senkronizasyon katmanı”.

Buradaki asıl mesaj kimin kimi aldığı değil. Asıl mesaj, bir veri platformu şirketinin, ajanların kod çalıştırdığı sandbox’ın içine gerçek bir ilişkisel veritabanı koymaya yatırım yapması. Veritabanı, uygulamanın arkasındaki merkezi kurumdan çıkıp ajanın yanındaki tek kullanımlık bir araca dönüşüyor. Bir sonraki haber, bunun neden bu kadar pahalı bir bahis olduğunu gösteriyor.

2. Databricks 190 milyar dolar: term sheet kapandı, para ajan altyapısına gidiyor

Geçen ayki derlemede, Databricks’in 188 milyar dolar değerleme üzerinden stratejik bir tur için term sheet imzaladığını, ama turun henüz kapanmadığını yazmıştım. Bu hafta o dosya kapandı: 13 Ağustos’ta Databricks, turu 190 milyar dolar değerleme üzerinden ve 5 milyar dolar büyüklüğünde kapattığını açıkladı. Turu Coatue liderliğinde; Blackstone, MGX, T. Rowe Price ve yeni yatırımcı Sixth Street Growth ile birlikte BOND, Clearlake, Point72, Premji Invest ve TPG’nin de içinde olduğu bir yatırımcı grubu tamamladı.

Rakamların altını çizeyim, çünkü hız hikayenin kendisi: Databricks bu turu, değerlemesini 134 milyar dolara koyan turdan yaklaşık altı ay sonra kapatıyor. Gelir tarafında da şirket, 7 milyar doları aşan bir yıllıklandırılmış gelir oranına ulaştığını ve %80’in üzerinde yıllık büyüme kaydettiğini söylüyor. (Bu gelir ve büyüme rakamları şirket beyanıdır; özel şirket olduğu için bağımsız denetimli finansallarla sahada teyit edilmiş değil.)

Paranın nereye gideceği, birinci haberle doğrudan bağlanıyor. Databricks, bu sermayenin bir kısmını Lakebase, Genie ve Unity AI Gateway gibi, büyük kurumların içinde ajan çalıştırmak için altyapı olarak konumlandırdığı ürünleri büyütmeye ayıracağını söylüyor. Aynı Lakebase: ajanlar için sunucusuz Postgres. Şirketin verdiği rakama göre Lakebase tek başına 100 milyon doları aşan bir yıllıklandırılmış gelir oranına ulaşmış (yine şirket beyanı).

Neden-sonuç kısmı: Bir önceki derlemede bu turun amacının halka arz değil, satın alma kapasitesi olduğunu yazmıştım. Bu hafta o teze bir kanıt geldi: turun kapandığı hafta, Databricks aynı zamanda Electric’i satın aldı. Yani “para topla, ajan altyapısı kur, o altyapıyı besleyen küçük oyuncuları satın al” döngüsü artık teorik değil, takvimde yan yana duruyor.

Sizin için pratik sonucu değişmedi, sadece güçlendi: data ekosisteminde bağımsız kalan orta ölçekli oyuncu sayısı azalmaya devam edecek. Electric bunun bu haftaki örneği. Kendi stack’inizde küçük bir vendor’a kritik biçimde bağlıysanız, o vendor’un bir yıl sonra kimin altında olacağı ciddi bir mimari risk kalemi.

3. PostgreSQL: rekor bir güvenlik dalgası ve sessizce gelen 19 Beta 3

Ajan heyecanının arasında kaybolmaması gereken haber bu, çünkü altyapının sıkıcı ama hayati tarafını hatırlatıyor. 13 Ağustos’ta PostgreSQL ekibi eşzamanlı olarak 18.6, 17.11, 16.15, 15.19, 14.24 bakım sürümlerini ve 19 Beta 3‘ü yayınladı.

Bu sadece rutin bir yama değil. Bu sürüm 28 güvenlik açığını (CVE) ve 110’dan fazla hatayı kapatıyor. Rakamı çerçeveleyin: 28 CVE, PostgreSQL’in tek bir sürümde şimdiye kadar kapattığı en yüksek sayı; önceki rekor bir çeyrek önce, Mayıs’ta konan 11’di. Açıkların önemli bir kısmı heap buffer overflow ve integer wraparound türünden, yani kimlik doğrulaması olmayan bir saldırganın sunucu üzerinde kod çalıştırmasına yol açabilecek sınıftan. İki örneği isimleriyle vereyim ki ciddiyeti otursun: CVE-2026-14669, to_char(timestamptz) içinde uzun bir POSIX zaman dilimi kısaltmasıyla tetiklenen bir heap buffer overflow üzerinden kod çalıştırmaya; CVE-2026-18408 ise pg_dump çıktısına güvenilmeyen veri enjekte edilerek restore anında kod çalıştırmaya izin veriyordu.

Bir operasyonel notu da atlamayın: bu seri, 18.5 sürümünü atladı; 18.5, bir regresyon nedeniyle yayınlanmadı ve doğrudan 18.6’ya geçildi. Yani “bir eksik minor sürüm” gördüyseniz sistemde bir sorun yok, kasıtlı.

İkinci hatırlatma takvimle ilgili: PostgreSQL 14, 12 Kasım 2026’da destek dışına çıkıyor. 14 hala üretimdeyse, artık son yamalarını sayıyorsunuz demektir; yükseltme planını bu sürümle birlikte netleştirin.

Beta cephesinde ise PostgreSQL 19 Beta 3 çıktı; nihai sürüm normal takvimine göre Eylül-Ekim 2026 civarında bekleniyor. Bu beta, birleşik bir REPACK komutu, SQL property graph sorgu desteği ve geliştirilmiş temporal (zamansal) veri işleme gibi kalemler getiriyor; performans tarafında ise NOT IN ifadelerinin otomatik olarak ANTI JOIN’e çevrilmesi ve varsayılan TOAST sıkıştırmasının LZ4‘e geçmesi öne çıkıyor.

Neden-sonuç kısmı: Buradaki gerilim, bu yazının tam ortasında duruyor. Bir tarafta herkes veritabanını ajan için yeniden hayal ediyor: property graph, temporal sorgu, gömme, hepsi motorun içine giriyor. Beta cephesindeki property graph ve temporal işlemenin PostgreSQL 19’a gelmesi de tam olarak bu yönün açık kaynak tarafındaki karşılığı. Ama diğer tarafta, aynı hafta çıkan 28 CVE’lik rekor dalga şunu söylüyor: ne kadar akıllı özellik eklerseniz ekleyin, o veritabanı hala yamalanması, sürümü takip edilmesi ve destek takvimi izlenmesi gereken bir sistem. Ajanınıza en gelişmiş vektör ve graf yeteneğini verebilirsiniz; yamasız bir sunucuda çalışıyorsa, verdiğiniz şey bir güvenlik açığı olur. Heyecanlı kısım ile sıkıcı kısım aynı motorun iki yüzü.

4. MongoDB Build Fest: gömme, yeniden sıralama ve yönetilen bir MCP sunucusu

13 Ağustos’ta MongoDB, MongoDB.local Build Fest etkinliğinde arama ve getirme (retrieval) tarafında bir dizi yeni yeteneği duyurdu. Öne çıkanlar: Atlas üzerinde Voyage AI ile çalışan Automated Embeddings (otomatik gömme), Atlas Embedding ve Reranking API, yeni bir kod modeli olan voyage-code-4, Atlas Stream Processing içinde vektör arama. Şirketin duyurusuna göre bu dört yetenek genel kullanıma (GA) açıldı. Aynı gün, ayrı bir duyuruyla Atlas Managed MCP Server da kullanıma açıldı; bu ikincisi için duyuruda “GA” ifadesi geçmiyor, “bugünden itibaren kullanılabilir” deniyor.

En pratik olanı Automated Embeddings. Yaptığı iş şu: veri eklendiğinde, güncellendiğinde ya da sorgulandığında gömmeleri (embedding) otomatik üretip saklıyor. Yani ayrı bir gömme hattı ya da dışarıda bir servis işletmenize gerek kalmıyor; bu adım veritabanının kendi içinde oluyor. RAG ve ajan projelerinde en çok emek yiyen, en çok kırılan yerlerden biri tam olarak bu boru hattıdır; onu motorun içine almak sıradan bir kolaylık değil.

voyage-code-4 tarafında GA/rakam ayrımını dikkatle verin. Model, kodlama ajanları için (agentic code retrieval) özel olarak eğitilmiş, 32K bağlam penceresine sahip ve fiyatı 1 milyon token başına 0,12 dolar, yani bir önceki voyage-code-3’ten yaklaşık üçte bir daha ucuz. Karşılaştırma rakamlarını ise olduğu gibi vereyim, çünkü hangi kıyaslamaya baktığınıza göre ciddi biçimde değişiyorlar. Voyage’ın kendi duyurusuna göre voyage-code-4, kodlama ajanlarının kodu nasıl getirmesi gerektiğini ölçmek için kurulmuş yeni bir kıyaslamada Cohere Embed v4’ü ortalama %28,25, Gemini Embedding 2’yi %31,03 geride bırakıyor. Ama voyage-code-3’ün değerlendirmesinde kullanılan 28 kod getirme veri setinde aynı fark %19,21 ve %16,01‘e iniyor. Yani üstünlük, modelin kendi tasarladığı kıyaslamada yaklaşık iki katına çıkıyor. Bunların tamamı vendor iddiasıdır, bağımsız kıyaslamalarla sahada teyit edilmiş değildir. Duyurudaki “sektör lideri isabet” gibi ifadeleri de aynı kategoride okuyun.

Aynı gün duyurulan ikinci bir başlık var ki bu yazının tezine belki hepsinden daha yakın: MongoDB Atlas Managed MCP Server. Şimdiye kadar bir ajanı canlı operasyonel veriye bağlamak isteyen ekip, o bağlantıyı kendisi kurup kendisi işletiyordu. Artık MCP sunucusu Atlas’ın içinde bir servis olarak, uzaktan ve tam yönetilen biçimde çalışıyor; kurulacak, işletilecek ya da yükseltilecek bir şey yok. Bağlandıktan sonra ajan koleksiyonları ve indeksleri listeleyebiliyor, sorgu ve toplama çalıştırabiliyor, şema inceleyebiliyor, yetki verilmişse koleksiyon oluşturup indeks yönetebiliyor. Bağlanan taraf listesinde Claude Code, Codex, Grok Build ve Devin gibi kodlama ajanları var. MongoDB’nin paylaştığı rakama göre MCP sunucusu şimdiden haftada 30 binden fazla kurulum alıyor.

Ama buradaki asıl önemli ayrıntı yetenek listesi değil, onun hemen yanındaki şu cümle: ekipler Atlas’ta zaten kullandıkları kimlik bilgileri ve erişim kontrolleriyle bağlanıyor, yani yönetici ajanların operasyonel veriye nasıl eriştiğini tek yerden yönetebiliyor. Ajan erişimini ayrı bir kapı olmaktan çıkarıp mevcut yetkilendirme modelinin içine almak, bu işin demoyu geçip üretime çıkan kısmı. Bir ajana veritabanı yetkisi vermek, kolay tarafı; o yetkiyi kimin, hangi rolle, hangi kayıt altında kullandığını gösterebilmek zor tarafı.

Neden-sonuç kısmı: Bu, PostgreSQL bölümünde anlattığım yakınsamanın NoSQL cephesindeki halkası. Vektör arama iki yıl önce başlı başına bir ürün kategorisiydi; sonra genel amaçlı veritabanlarının içine indi. Şimdi bir adım daha: sadece vektör aramanın kendisi değil, gömme üretimi ve yeniden sıralama (reranking) gibi getirme hattının parçaları da veritabanının içine giriyor. Bunun sizin için pratik sonucu şu: 2026’da bir getirme (retrieval) mimarisi kurarken “gömme servisi + vektör veritabanı + reranking servisi” diye üç ayrı kutu çizmeden önce, zaten kullandığınız veritabanının bu üçünü ne kadar tek başına yaptığına bakın. Bu konudaki uzun yolculuğu daha önce Veritabanı İçerisine Vektör Aramanın Kısa Tarihi yazısında kronolojik olarak çıkarmıştım; MongoDB’nin bu hamlesi o kronolojinin mantıklı bir sonraki halkası.

5. Açık kaynak cephesi: lakehouse katalogları da olgunlaşıyor (Apache Polaris)

Son haber teknik bir manşet değil, ama tabloyu tamamlayan bir olgunlaşma işareti. Lakehouse dünyasının katalog katmanında, Apache Polaris 1.7.0 2 Ağustos’ta yayınlandı ve etkileri (özellikle güvenlik tarafı) haftanın içine taştı. 1.7.0, olayları yayınlamak için bir Kafka olay dinleyicisi, vendor edilen kimlik bilgilerinde GCS principal atıfı (yani Polaris principal’ının GCS erişim kayıtlarında görünmesi) ve üretilen tablo konumlarına öngörülemez benzersiz sonekler veren bir bayrak gibi, çoğu yönetişim ve denetim tarafına dokunan iyileştirmeler getiriyor.

Aynı sürüm çevresinde CVE-2026-64640 açıklandı. Bu, 1.6.0’a kadar olan Polaris sürümlerini etkileyen düşük önem dereceli bir açık: register uç noktası, çağıranın seçtiği bir Iceberg metadata dosyasını, dosyanın izinli depolama konumunda olup olmadığını doğrulamadan önce kataloğun kimlik bilgileriyle okuyordu; kayıt yetkisi olan bir principal, kataloğun erişebildiği nesnelerden sınırlı bilgi sızdırabiliyordu. Etki gizlilikle (confidentiality) sınırlı; veri bozma ya da kod çalıştırma yok. Aynı hafta Iceberg tarafında da spec oylamaları ilerledi ve Parquet sürümleme tartışması yeniden açıldı.

Neden-sonuç kısmı: Bunu neden derlemeye aldığımı açayım. PostgreSQL bölümünde ajan yeteneği ile güvenlik disiplininin aynı motorun iki yüzü olduğunu söylemiştim; Polaris haberi aynı ikiliğin lakehouse katalog katmanındaki karşılığı. Ajanlar artık bu katalogları okuyup yazan taraf haline geldikçe, “kim hangi tabloyu görebilir”, “üretilen tablo konumu tahmin edilebilir mi”, “vendor edilen kimlik bilgisi kimin adına kullanıldı” gibi sorular birer konfor kalemi olmaktan çıkıp güvenlik kalemine dönüşüyor. Katalog, sessizce yönetişim katmanına terfi ediyor. Iceberg fiili standart olmaya devam ederken, standardın etrafındaki katalog ve güvenlik altyapısının bu şekilde olgunlaşması, teknolojinin ilgi çekici olmayan ama en belirleyici kısmı.

Hepsini bağlayalım: beş haber, tek neden

Başa dönelim. Bir satın alma, bir yatırım turu kapanışı, bir güvenlik yaması, bir konferans duyurusu, bir katalog sürümü. Ortak paydaları ne?

Hepsi, veritabanı katmanını ajan için yeniden şekillendiriyor. Sadece farklı yerlerinden tutarak:

Electric / PGlite veritabanının yerini değiştiriyor: merkezden çıkarıp ajanın yanındaki tek kullanımlık bir araca indiriyor.
Databricks’in 190 milyarı bu işin faturası: piyasa, ajan altyapısının (Lakebase, Genie, Gateway) gerçek bir kategori olduğuna 5 milyar dolarlık bahis oynuyor.
MongoDB getirme hattını içeri alıyor: gömme ve yeniden sıralama artık ayrı servis değil, veritabanının işi. Yönetilen MCP sunucusuyla da ajanın veriye açılan kapısını veritabanının kendi yetkilendirme modelinin içine koyuyor.
PostgreSQL 19 Beta 3 aynı yeteneği (property graph, temporal) açık kaynak tarafında motorun içine koyuyor; ama aynı günkü 28 CVE, bu motorun hala yamalanması gereken bir sistem olduğunu hatırlatıyor.
Apache Polaris ise ajanların okuyup yazdığı katalog katmanını yönetişim ve güvenlik tarafından sıkılaştırıyor.

Peki bu sizin için ne demek? Üç somut çıkarım bırakayım:

Bir: Yeni bir özel sistem eklemeden önce mevcut veritabanınızın ne yapabildiğine bakın. Gömme, vektör arama, reranking, hatta ajan başına yerel bir örnek: 2026’da bunların çoğu için ayrı bir ürün kurmak, iki yıl öncesine göre çok daha zayıf bir savunma. “Zaten kullandığım motor bunu yeterince iyi yapıyor mu” sorusu artık ilk soru olmalı.

İki: Ajan altyapısını heyecanla kurarken güvenlik ve sürüm disiplinini aynı masaya koyun. Bu hafta bunun kanıtı çıplak haldeydi: aynı gün hem PostgreSQL’e ajan dostu özellikler geldi, hem de tek seferde rekor 28 CVE kapandı. Ajanınıza en gelişmiş yeteneği verip onu yamasız bir sunucuda çalıştırmak, hata değil, açık üretir. PostgreSQL 14 kullanıyorsanız 12 Kasım tarihini takvime yazın.

Üç: Vendor konsolidasyonunu mimari risk olarak yazın. Databricks’in savaş sandığı bunun için topluyor ve Electric örneği, ajan-yerel araçların ne kadar hızlı büyük bir platformun altına girebildiğini gösterdi. Kritik bir bağımlılığınız küçük bir oyuncudaysa, çıkış planınız olsun.

Bu tür gündem yazılarının arasında sürüm ve erişilebilirlik takibini de ihmal etmeyin. PostgreSQL’i üretimde işletiyorsanız yüksek erişilebilirlik tarafını daha önce PostgreSQL Yüksek Erişilebilirlik Seçenekleri yazısında toplamıştım; ajan projelerine başlamadan önce veri kalitesi ve yönetişim tarafına da Veri Kalitesi = AI Kalitesi: İyi Verinin 4 Ölçütü yazısındaki dört ölçüt üzerinden bakabilirsiniz.

Bu konuların sizin ortamınızda ne anlama geldiğini konuşmak isterseniz, DMC Bilgi Teknolojileri olarak yönetilen veritabanı hizmetleri tarafında SQL Server’ın yanı sıra PostgreSQL ve MongoDB yönetimi de yapıyoruz. Yazının ikinci çıkarımına, yani güvenlik yaması ve sürüm disiplinine denk gelen tarafta veri güvenliği, ajan erişimi ve yönetişim tarafında ise yapay zeka hizmetleri başlıklarına bakabilir ya da doğrudan iletişim sayfasından yazabilirsiniz.

Bu haftalık formatı beğeniyorsanız düzenli hale getiriyorum. Hangi başlığı daha derin işlememi istersiniz, yorumlarda yazın. 🙂

Kaynaklar

Aşağıdaki bağlantıların tamamı 17 Ağustos 2026 itibarıyla kontrol edildi. Rakamların bir kısmı (özellikle Databricks’in gelir ve büyüme beyanları, Lakebase gelir oranı ve MongoDB’nin voyage-code-4 kıyaslama sonuçları) üretici beyanıdır; yazı içinde bunu ayrıca belirttim. Bazı birincil kaynak sayfalarına (postgresql.org, databricks.com, mongodb.com) ait bağlantılar doğrudan verilmiştir; içerik birden fazla bağımsız kaynakla karşılaştırılarak doğrulanmıştır.