Ölçeklenecek bir SaaS için doğru varsayılan seçim PostgreSQL’dir. Bir web ya da mobil ürünün ihtiyaç duyduğu şeyin yaklaşık %90"ını karşılar: işlemsel veriler, varlıklar arası ilişkiler, arama, JSON, hafif kuyruklar ve hatta AI için vektör yükünün bir kısmı. Asıl soru neredeyse hiçbir zaman "ilişkisel mi NoSQL mi" değildir; "Postgres’i KULLANMAMAK için somut bir nedenim var mı" sorusudur. Çoğu zaman, yok.
Varsayılan olarak PostgreSQL: neden 10"da 9 işe yarar
Bir SaaS, yapılandırılmış ve birbirine bağlı verilerle çalışır: organizasyonlara ait kullanıcılar, faturalara bağlı abonelikler, görevlere bağlı projeler. İlişkisel veritabanları tam da bunun için yaratılmıştır. Postgres bu temele, ek araçlar istiflemekten kurtaran süper güçler ekler: yarı yapılandırılmış veriler için JSONB sütunları, yerleşik tam metin araması, AI embedding’leri için pgvector eklentisi ve verilerinizin bütünlüğünü güvence altına alan kısıtlar.
- ACID işlemleri: ödemeleriniz ve kritik verileriniz, bir çökme sonrasında bile tutarlı kalır.
- Üç yerine tek bir sistem işletmek, yedeklemek ve izlemek: daha az maliyet, daha az kesinti.
- Olgun ekosistem: Prisma, migration’lar, replikasyon, her yerde yönetilen hosting (Cloud Run, Neon, Supabase, RDS).
- Esnekliğe ihtiyaç duyduğunuzda JSONB, gerisi için ilişkiselden vazgeçmeden.
İlişkisel vs NoSQL: Postgres’ten ne zaman çıkmalı
NoSQL (MongoDB, DynamoDB, Firestore) "daha modern" değildir; farklı kısıtlara yanıt verir. Yalnızca kullanım senaryonuz gerçekten uyuyorsa kazandırır: yazma ağırlıklı devasa hacim, gerçekten öngörülemez bir şema ya da aşırı coğrafi dağıtım ihtiyacı. Lansman ve büyüme aşamasındaki tipik bir B2B SaaS için bu kısıtlar henüz yoktur; NoSQL’i çok erken benimsemek, asla kullanmayacağınız bir şey için karmaşıklıkla ödeme yaptırır.
200 kullanıcınız varken "ölçekleniyor" diye NoSQL seçmek, sahip olmadığınız bir sorunu, zaten sahip olduklarınızın pahasına optimize etmektir.
İndeksler, migration’lar, ölçekleme: V1"den itibaren üç refleks
İyi seçilmiş bir veritabanı yeterli değildir: SaaS’inizin 10.000 kullanıcıda dayanıp dayanmayacağına üç alışkanlık karar verir. Önce indeksler: bütün bir tabloyu tarayan bir sorgu 100 satırda hızlı, 1 milyonda felakettir. Sık filtreleyip birleştirdiğiniz sütunları indeksleyin ve EXPLAIN ile ölçün. Sonra migration’lar: her şema değişikliği versiyonlanmış ve yeniden çalıştırılabilir olmalı (Prisma Migrate), asla üretimde elle uygulanmamalı. Son olarak ölçekleme: önce dikey (daha fazla CPU/RAM), ardından okuma replikaları ve sharding yalnızca çok geç düşünülür: çoğu SaaS oraya hiç ulaşmaz.
- İndeksler: WHERE, JOIN ve ORDER BY yan tümcelerindeki sütunları hedefleyin; kötü bir indeks yazmaya mal olur, eksik bir indeks okumayı öldürür.
- Migration’lar: versiyonlanmış, test edilmiş, geri alınabilir: veritabanı, kesinti olmadan ürünle birlikte gelişir.
- Ölçekleme: önce dikey, sonra okuma replikaları; Postgres, sharding gündeme gelmeden çok önce milyonlarca satırı kaldırır.
Bir V1 için doğru karar
İlk günden PostgreSQL’i seçmek, temiz modellemek, doğru indeksleri koymak ve migration’ları versiyonlamak: 12. ayda yeniden yazmaktan sizi kurtaran şey budur. Bu, 7 günde 15.000 €"ya teslim ettiğimiz V1"lerde kurduğumuz temelin ta kendisidir — Next.js, NestJS, Prisma ve Postgres — ilk müşterinizden ölçeğe geçişe kadar sizinle gelen, gizli teknik borcu olmayan bir veritabanı.