Şemayı sürprizsiz değiştirmek: Supabase dalları, pg-delta ve Cloudflare'de milyonlarca SQLite

Bir haftada veritabanı yapısı hakkında dört yazı çıktı. Supabase, projenin kopyası olan bir dalın nasıl oluşturulduğunu ve migration'ların artık pg-delta ile nasıl kurulduğunu gösterdi. Cloudflare, D1'in milyonlarca SQLite veritabanını nasıl taşıdığını anlattı. PlanetScale, shard'lı Postgres'te sequence'in neden tek bir shard'a bırakılamayacağını açıkladı. PostgreSQL haberlerinde ise Oracle'dan geçişi değerlendiren pgrecon duyuruldu. Ortak konu tek: veri yapısındaki değişiklik öngörülebilir olmalı. İşletme için bu şöyle görünür: siparişe yeni bir alan eklendi ve ne bir rapor ne de bir entegrasyon bozuldu.

Neler çıktı

Supabase 15 Ekim'de yeni bir dalın yapılandırmasını, migration'larını ve fonksiyonlarını nasıl aldığını anlattı. Dal ayrı bir proje. Oluşturulurken üç kısım paralel ilerliyor: ana projeden ayarların kopyalanması, migration'lar ve Edge Functions'ın dağıtımı; hazır olma süresinin medyanı yaklaşık 20 saniye. Her migration dosyası tek bir transaction olarak çalışıyor. Her adımın bir durumu var: RUNNING, EXITED, PAUSED ya da DEAD. Böylece bir arıza olduğunda neyin çalışmaya yetiştiği görülüyor.

13 Ekim'de Supabase, 2 Ekim'de Supabase Select'te gösterilen pg-delta üzerindeki Declarative Schemas 2.0'ı anlattı. Şema SQL dosyalarında tutuluyor, migration'ı CLI kendisi yazıyor. pg-delta iki geçici veritabanı açıyor: birine şema dosyalarını yüklüyor, diğerinde migration geçmişini baştan çalıştırıyor, ikisini sistem kataloğu üzerinden karşılaştırıyor ve sonucu bağımlılık grafiğine göre sıralıyor. Diff'e artık RLS politikaları, grant'ler, domain'ler, partition'lar ve eklenti nesneleri de giriyor; yıkıcı çağrıları CLI ayrıca işaretliyor.

PlanetScale 14 Ekim'de, shard'lı Postgres'leri Neki'de sequence ve diğer volatile ifadeler hakkında bir not yayımladı. router-only denen bir ifade sınıfı var: now() farklı shard'larda saat kayması yüzünden farklı zaman verir, bu yüzden yönlendiricide istek başına bir kez hesaplanıyor. Sequence de aynı nedenle bir merkez gerektiriyor: numaranın tekrarlanmayacağı garantisi shard'lar arasında bölünemez.

Cloudflare 13 Ekim'de D1'in milyonlarca veritabanına nasıl ölçeklendiğini anlattı. D1, onların SQLite üzerindeki sunucusuz veritabanı. Rakamlarına göre 8 Ekim 2026 itibarıyla canlı veritabanı sayısı bir yılda 15 kat, iki yılda 65 kat arttı; günlük aktif veritabanlarının sayısı da bir yılda 18 kat. Saydıkları ilkeler şunlar: her süreci arızaya ve yan etkisiz yeniden çalıştırmaya göre tasarlamak, istek yoluna merkezi bileşen koymamak ve sistemi gerçeğe yakın bir yükle test etmek.

22 Ekim'de PostgreSQL haberlerinde pgrecon 0.7.3 çıktı: Oracle'dan PostgreSQL'e geçişi değerlendiren, Apache-2.0 lisanslı bir araç. Çevrimdışı çalışıyor: salt okunur bir script döküm alıyor, araç bu dökümden bir envanter çıkarıyor, 80 kuraldan geçiriyor ve adam-gün cinsinden bir aralık veriyor. Taşınamayan her şey ayrı bir kalan işler raporuna giriyor.

Örnek: kiralama şirketi çocuk koltuğu ekliyor

Bir araç kiralama şirketi rezervasyonları Google E-Tablolar'da tutuyor ve “çocuk koltuğu ücreti” sütunu ekliyor. CRM entegrasyonu eski sütun setini bekliyor, yöneticilerin uygulaması yeni alanı bilmiyor, gelir raporu da yanlış şeyi topluyor. Bu, araçsız ve kontrol edilebileceği bir dal olmadan yapılmış bir şema migration'ı. Güney Afrika'da ben de buradan başlamıştım: ilk işim AmoCRM'i Google E-Tablolar'la bağlamak ve bakım maliyetinin, kilometrenin ve çocuk koltuğu ücretinin orada güncellenmesini sağlamaktı. Sonra FlutterFlow'daki uygulamanın alanlarını AmoCRM ile eşleştirdim ve seçilen alanlar için senkronizasyon kurdum. Şema sistemler arasındaki bir sözleşmedir; onu bütün tarafların önceden haberi olacak şekilde değiştirmek gerekir.

Bende nasıl çalışıyor

Şirket içi bir servis olan “Birlikte Kahve” React ve TypeScript ile yazıldı. 2 GB bellekli ortak sunucuda, Cloudflare Workers runtime'ında, Docker volume'daki yerel SQLite veritabanı üzerinde D1 API ile çalışıyor. kononov.dev sitesi de SQLite üzerinde.

Cloudflare'in ilk ilkesi, yan etkisiz yeniden çalıştırma, bende “Birlikte Kahve”de işliyor: eski Google E-Tablo'dan içe aktarma günlüğü siparişi kaynak satırın numarasına bağlıyor, bu yüzden yeniden yükleme kopya oluşturmuyor, değişmiş bir satır da çakışma olarak gösteriliyor. Yanında kendim uyguladığım bir kural var: başarısız bir adım çalışan verileri bozmaz. Katalog, Tasty Coffee'nin toptan API'siyle zamanlanmış olarak senkronize ediliyor ve başarısız bir deneme yayımlanmış kataloğu silmiyor.

ABD'deki PDR şirketinde 2023'te hız ve tek veri formatı için Google E-Tablolar'dan SQL veritabanına geçmeyi önerdim. Fikir desteklendi ve MariaDB'ye geçtikten sonra yeni servisleri birer birer bağladık. Her migration'ı önce veritabanının bir kopyasında çalıştırıp ancak sonra yayına almak daha iyi. Supabase dallarını, pg-delta'yı ve pgrecon'u kendimde çalıştırmadım, açıklamalara göre değerlendiriyorum.

Ben ne yapardım

Migration'ları depoda sürüm numaralı dosyalar olarak tutun, uygulanan sürümlerin tablosu da veritabanının kendisinde olsun. Supabase de böyle yapıyor.

Her migration'ı çalışan veritabanının dünkü kopyasında, uygulama ve raporlarla birlikte çalıştırın.

Alanları iki adımda değiştirin: önce yenisini ekleyin ve bütün sistemleri ona geçirin, eskisini ise tüketici listesi boşaldığında ayrı bir yayınla silin.

Aracın yazdığı diff'i gözle okuyun, özellikle yıkıcı olarak işaretlenen her şeyi.

Farklı veritabanı yönetim sistemleri arasında geçiş yapıyorsanız, pgrecon örneğindeki gibi envanterle ve taşınamayanların listesiyle başlayın.

Sistemin durumunun neden tek bir yerde yaşaması gerektiğini sistemin çekirdeği olarak sunucu yazısında anlattım. Bu incelemedeki servis: “Birlikte Kahve”. Veritabanında sonradan pişman olunan üç karar cascade silme, shard'lar ve replikalar incelemesinde, platformlar ile kendi sunucu Vercel, Fly ve Supabase'deki backend'ler incelemesinde, güncellemelerin etki alanı da Netflix'in aracı ve TypeScript 7.1 incelemesinde. Veritabanı güncellemesinden önce aradaki proxy'leri daha önce kontrol etmiştim. Hizmet alanları: altyapı ve DevOps ve iç sistemler. Çalışan bir sistemde veri yapısını değiştirmeniz gerekiyorsa neyin değiştiğini ve bu veriyi kimin kullandığını anlatın. Görevi konuşalım.