Startup İçin Veritabanı Seçimi
25 Şubat 2026
PostgreSQL, MySQL ve MongoDB karşılaştırmasından managed servis seçimine, ne zaman managed DB gerektiğinden ölçekleme noktalarına kapsamlı veritabanı rehberi.
PostgreSQL vs MySQL vs MongoDB
PostgreSQL, ACID uyumluluğu, güçlü JSON desteği (JSONB), yerleşik full-text search ve kapsamlı extension ekosistemiyle çoğu startup için varsayılan veritabanı tercihi haline gelmiştir. Karmaşık sorguları, ilişkisel veri yapılarını ve işlem bütünlüğü gerektiren finans veya sipariş akışlarını güvenle yönetir. pgvector extension'ı ile aynı veritabanında vektör araması da yapabilmesi YZ özellikli ürünler için ayrı bir avantaj oluşturuyor.
MongoDB schema-less esnekliğiyle hızlı prototipleme sürecinde caziptir; sabit şema tanımlamadan yazma yapabilmek ilk haftaları hızlandırır. Ancak JOIN yokluğu karmaşık çok-tablolu sorgularda ciddi sorun çıkarır ve zamanla veri tutarsızlığı birikmesine zemin hazırlar. Gerçek anlamda belge modeline uyan kullanım alanları için değerlidir: log verisi, dinamik form yanıtları, hiyerarşik içerik. Ama tipik bir SaaS ürününün kullanıcı-sipariş-fatura ilişkisi PostgreSQL'in doğal olduğu modeldir.
Managed Servis Karşılaştırması
Supabase, PostgreSQL tabanlı managed bir backend'dir. Ücretsiz tier 500 MB veri ve 2 proje sunar; Row Level Security ile veritabanı düzeyinde yetkilendirme yapılabiliyor ve bu özelliğin doğru kullanımı bir güvenlik katmanı olarak ek değer yaratıyor. Realtime subscription, auth ve storage dahildir; erken aşama startup için hem hız hem de maliyet açısından güçlü bir başlangıç noktası.
PlanetScale, MySQL uyumlu serverless bir veritabanı platformudur. Branch-based schema migration özelliği, veritabanı şemasını kod gibi dal yönetimiyle değiştirmeni sağlar ve zero-downtime deploy'u mümkün kılar. Railway ise PostgreSQL, Redis ve MySQL dahil birden fazla servisi tek platformda sunan, $5/ay'dan başlayan minimal konfigürasyonlu bir çözümdür. Kubernetes veya container yönetimiyle uğraşmak istemeyenler için Railway en az yönetim yüküyle başlangıç yapmak anlamına gelir.
Ne Zaman Managed DB Gerekli
Kendi sunucuna PostgreSQL kurabilirsin; ama yedekleme, güvenlik yamaları, failover ve performans izleme sorumluluğunu da üstlenmiş olursun. Managed servis bu operasyonel yükü devralır ve çoğu startup için bu takas net pozitif değer üretir. İlk $50K MRR'a kadar managed servis maliyeti genellikle bir backend geliştirici maaşının küçük bir kesimine karşılık gelir ve operasyonel yükü sıfır tutar.
Kendi sunucuna geçmeyi düşünmen için belirgin bir neden olmalıdır: managed servis faturan $500/ay'ı geçiyor ve kendi sunucu maliyeti anlamlı ölçüde düşük olacak, veya regülasyon nedeniyle tam veri kontrolü gerekiyor, ya da çok spesifik bir konfigürasyon ihtiyacın var. Bu eşiğin altında kalmak, mühendislik kapasitesini veritabanı operasyonuna harcamak yerine ürüne yönlendirmek anlamına gelir.
Ölçekleme Noktaları
Üç sinyal veritabanı ölçekleme ihtiyacı doğurduğunu gösterir: sorgu süresi tutarlı biçimde 100ms'yi geçiyorsa, CPU kullanımı sürekli %80 üzerindeyse ve bağlantı havuzu sık sık doluyorsa. Bu noktaların herhangi birinde önce sorgular optimize edilmeli ve eksik index'ler tamamlanmalıdır; çoğu performans sorunu yatay ölçekleme değil, eksik index ile çözülür.
Index analizi için EXPLAIN ANALYZE çıktısını oku ve sequential scan'ları index scan'a dönüştür. Bağlantı havuzu sorunu için PgBouncer'ı veritabanı önüne eklemek çok sayıda kısa ömürlü bağlantının yönetimini kolaylaştırır. Okuma trafiği dominant ve yazma azınlıktaysa read replica eklenmesi CPU yükünü dengelemek için ilk adım olabilir. Yatay sharding son çare ve ciddi mühendislik yatırımı gerektirir; çoğu startup buna hiç ihtiyaç duymadan büyür.
Sık Sorulan Sorular
PostgreSQL ile MongoDB arasında seçim yapmanın pratik kriteri nedir? Verinin çoğu zaman birden fazla tabloyla JOIN gerektiriyorsa PostgreSQL; her kaydın bağımsız belge olarak anlam taşıdığı, dinamik şema gereksinimi varsa MongoDB. Kararsızsan PostgreSQL'in JSONB sütunu her ikisinin avantajını kısmen bir arada sunar.
Supabase ücretsiz tier üretim için yeterli mi? 500 MB veri ve 50MB/s bandwidth için yeterlidir. Erken aşama kullanıcı tabanı için sorunsuz çalışır. Haftalık aktif kullanıcı sayısı yüzleri aştığında paid tiere geçiş planla; özellikle realtime özelliği yoğun kullanılıyorsa bağlantı limitine daha erken ulaşılır.
PlanetScale'in branch-based migration nasıl çalışır? Her şema değişikliği bir "deploy request" olarak açılır, test ortamında doğrulanır ve ana branch'e merge edilir. Tıpkı git workflow gibi çalışır; production'a direkt şema değişikliği yapmak yerine her değişiklik inceleme ve geri alma mekanizmasıyla korunur.
Veritabanı faturasını azaltmak için ne yapılabilir? Sık çekilen sorgu sonuçlarını Redis veya in-memory cache ile önbellekle. Otomatik arşivleme ile büyük tablolardaki eski kayıtları cold storage'a taşı. Kullanılmayan index'leri sil; her index yazma işlemini yavaşlatır ve depolama tüketir.
Connection pool boyutu nasıl belirlenir? Toplam max_connections veritabanı kapasitesine ve sunucu belleğine bağlıdır. PgBouncer ile birlikte çalışırken pool boyutunu uygulama servis sayısı × ortalama eşzamanlı bağlantı formülüyle başlangıç değeri olarak hesapla, ardından gözlemle ve ayarla.
