Cloudflare, D1'in yapay zekâ ile üretilen uygulamalar için milyonlarca küçük veritabanına nasıl ölçeklendiğini anlattı

Cloudflare, D1'i tenant başına bir dünyaya göre yeniden yapılandırdı

Cloudflare, yönetilen serverless SQLite veritabanı D1 üzerine ayrıntılı bir mühendislik yazısı yayımladı ve servisin, büyük ölçüde yapay zekâ destekli geliştirme platformları tarafından oluşturulan milyonlarca veritabanını kaldırabilecek şekilde nasıl yeniden mimarileştirildiğini anlattı.

Cloudflare bloguna göre, geleneksel veritabanı tasarımı bir uygulamanın genellikle bir connection pooler öntaşındığı bir ya da iki büyük cluster üzerinde çalıştığını varsayar. Yapay zekâ destekli geliştirme ve sözde vibe coding platformları bu varsayımı tersine çeviriyor: her kullanıcı, uygulama, preview ortamı veya tenant için bir tane olacak şekilde pek çok küçük veritabanı doğuruyorlar. Her veritabanının Cloudflare tarafından yönetildiği ve yalnızca kullanılan kadar faturalandırıldığı D1 modeli bu yapıya uyuyor; ancak control plane ayak uydurabildiği sürece.

Yeniden tasarımın ardındaki büyüme

Cloudflare, D1'in 5,5 milyon veritabanı barajını aştığını bildiriyor. 8 Ekim 2026 itibarıyla canlı, silinmemiş veritabanlarının sayısı bir önceki yıla göre 15 kat, iki yıla göre ise 65 kat artmış; günde en az bir sorgu çalıştıran veritabanlarının sayısı ise yıl üzerinden 18 kat büyümüş durumda.

Şirkete göre köklü platformlar, herhangi bir Cloudflare müşterisinin kullanabildiği araçlarla D1 üzerinde inşa ediliyor. Yazıda, OpenAI'den Jon Abrams'ın ifadesine göre, gönderinin içinde yer aldığı üzere, dashboard'ları, oyunları ve araçları aracılığıyla kullanıcılara özel metrikler, leaderboard'lar ve yorumlar gibi özellikler sunmak için D1'e dayanan ChatGPT Sites örnek veriliyor.

Control plane nasıl kurgulandı

Cloudflare'ın açıklamasına göre her D1 veritabanı tek bir SQLite Durable Object tarafından destekleniyor ve milyonlarca veritabanı oluşturulmasını pratik kılan da bu. Dashboard, Wrangler ve Cloudflare CLI dahil tüm public API yüzeyleri, Cloudflare'ın edge gateway'inden geçerek bir D1 Edge API Worker'a ulaşıyor.

Bu worker trafiği iki türe ayırıyor. Query endpoint'leri ve bir D1 Worker binding kullanan uygulamalar, Cloudflare'ın Eyeball Worker adını verdiği bileşene yönlendiriliyor; bu proxy, Durable Object'lerin önünde durarak sorgu ele alımını, retry'ları, hata yönetimini ve gözlemlenebilirliği merkezileştiriyor ve ardından her isteği ilgili veritabanını taşıyan object'e iletiyor.

Veritabanı oluşturma, silme ve listelemenin yanı sıra import, export ve time travel'ı kapsayan geri kalan CRUD endpoint'leri ise, Cloudflare'ın connection pooling ürünü Hyperdrive üzerinden, Cloudflare'ın Core dediği merkezi bir Postgres cluster'ına hizmet veriyor. Hyperdrive yapılandırmalarından biri cache'siz ve primary'yi hedefliyor; diğeri cached ve read replica'ları hedefliyor. Küresel olarak dağıtılmış key-value store olan Workers KV ise, sorgu yolunun bağımlı olduğu veritabanı ID'sinden Durable Object ID'sine eşlemenin de dahil olduğu, okuma yoğun metadata için edge'de bir cache olarak konumlanıyor.

Cloudflare işlemleri resmi olarak üç düzleme ayırıyor: hızlı kalması gereken ve her zaman edge'de çalışan sorgular için bir data plane; merkezi tek bölge bileşenlerine bağımlı olabilecek API ve yaşam döngüsü işlemleri için bir control plane; ve nihai tutarlılıkla yetinebilen analitik ile faturalandırma işleri için bir arka plan asenkron düzlemi.

Saniyeler içinde veritabanı oluşturma

Bir veritabanı oluşturulduğunda sistem, ücretsiz katman ve hesap limitlerini kontrol ediyor, bir veritabanı UUID'si ve yeni bir Durable Object ID'si üretiyor, o object'i başlatıyor, Postgres'e bir metadata satırı yazıyor ve veritabanı-object eşlemesini Workers KV'ye kaydediyor. Yazıda gösterilen örnek bir Wrangler oluşturma işlemi, duvar saati süresiyle yaklaşık 1,6 saniyede tamamlanıyor.

Cloudflare'ın genellenebilir bulduğu ilkeler

Gönderi, Cloudflare'ın Developer Platform üzerinde control ya da data plane inşa eden herkese uygulandığını öne sürdüğü mühendislik ilkelerini sıralıyor. Her süreci hata ve idempotency için tasarla ki sistem kendini düzeltebilsin ve ilerlemeye devam edebilsin. Merkezi tek bölge bileşenlerini herhangi bir data plane hot path'inden uzak tut. Kritik yönlendirme metadata'sını Workers KV'ye yerleştir ki cache miss'ler nadiren merkezi veritabanlarına dokunmak zorunda kalsın. Merkezi Postgres'e erişim için mümkün olduğunca read replica'larla Hyperdrive kullan. Kullanıcı isteklerini ele alırken taramalar çalıştırmak yerine toplulaştırmaları veritabanında düzenli olarak önceden hesapla. Ve güçlü tutarlılığa ihtiyaç duymayan bileşenler arasinda queue'lara ve nihai tutarlılığa yaslan. Cloudflare, darboğazları bulup düzeltmek için beklenen büyümenin iyi üzerindeki bir hedefe karşı tekrar tekrar yük testi yaptığını da ekliyor.

Neden önemli

Gönderi, yapay zekâ destekli geliştirmenin altyapı varsayımlarını nasıl yeniden şekillendirdiğine dair somut bir sinyal. Bir uygulama için tek bir veritabanı boyutlandırmak yerine, platformlar giderek tenant başına ya da üretilen her uygulama için bir veritabanı sağlıyor ve zor problem, hepsini her sorguyu yormadan izleyen control plane'e kayıyor. Cloudflare'deki geliştiriciler için yazı, edge öncelikli sistemler için bir referans mimari işlevi de görüyor. Daha geniş endüstri içinse, veritabanı servislerinin giderek devasa sayıda küçük veritabanının ucuz ve hızlı şekilde sağlanması üzerinden değerlendirileceğini gösteriyor; klasik büyük-cluster-artı-connection-pooler tasarımının hiçbir zaman hizmet etmek için tasarlanmadığı bir iş yükü bu.