Vercel, Neon, Supabase, Firebase ve tek VPS ne kadar ölçeklenir?

Ölçeklemenin merdiveni

1. Statik sayfa ve CDN: en ucuz ve en çok yük taşıyan basamak.
2. Önbellek: sık okunan veriyi veritabanına gitmeden sun.
3. Sorgu ve indeks iyileştirme: çoğu yavaşlık kötü bir sorgudan gelir.
4. Bağlantı havuzu: çok sayıda eşzamanlı istekte veritabanı bağlantı sınırını korur.
5. Dikey ölçekleme: veritabanına ya da sunucuya daha fazla CPU ve bellek ver.
6. Okuma kopyaları: okuma yükünü başka sunuculara dağıt.
7. Servisleri ayırma ve parçalama (sharding): nadir ve en pahalı basamak.

Çoğu proje ilk dört basamağın ötesine hiç geçmez. Bu yüzden erken aşamada karmaşık mimari kurmak genellikle gereksizdir.

Vercel ve sunucusuz fonksiyonlar

Statik sayfalar ve CDN çok yüksek trafiği rahat taşır. Fonksiyonlar yük arttıkça paralel çalışır; asıl darboğaz çoğu zaman fonksiyonların konuştuğu veritabanıdır. Her fonksiyon örneği kendi bağlantısını açabildiği için birkaç yüz eşzamanlı istek bir Postgres'in bağlantı sınırını doldurabilir.

Neon ve Postgres

Neon, bağlantı havuzunu PgBouncer ile sunar; havuzlu bağlantı adresinde ana bilgisayar adına -pooler eklenir ve havuz, çok sayıda istemci bağlantısını daha az sayıda gerçek Postgres bağlantısına dönüştürür. Havuz işlem (transaction) modunda çalıştığı için SET, LISTEN ve NOTIFY ya da oturum düzeyinde kilitler gibi oturum durumuna dayanan özellikler beklediğin gibi davranmaz. Uygulama trafiği için havuzlu, migrasyonlar için doğrudan bağlantı adresini kullanmak yaygın bir ayrımdır.

Ölçekleme açısından Neon'un hesaplama gücü plana göre otomatik büyür (Ekim 2026 itibarıyla ücretsiz planda 2 CU'ya, ücretli planlarda daha yükseğe kadar). Bir Postgres dikey ölçeklemeyle, indeksle ve okuma kopyalarıyla çoğu uygulamaya yeter.

Supabase

Supabase altında standart Postgres çalıştırır, yani Postgres için geçerli ölçekleme kuralları burada da geçerlidir: indeks, havuz, daha büyük örnek ve okuma kopyaları. Küçük bir örnekten başlayıp büyütebilirsin. Ücretsiz planda hareketsiz projelerin duraklatılacağını unutma.

Firebase ve Firestore

Firestore yatay ve otomatik ölçeklenir, bu yüzden trafik artışını sunucu yönetmeden taşır. Bedeli veri modeli ve maliyettir: okuma ve yazma sayısı faturayı belirler ve tek bir belgeye saniyede sürekli yazılabilecek yazma sayısı sınırlıdır (yaklaşık saniyede bir). Sorguları ve belge yapısını baştan buna göre tasarlamak gerekir.

Tek bir VPS

Tek bir VPS, düşük ve orta trafik için şaşırtıcı derecede yol alır, çünkü darboğaz genelde CPU'dan önce veritabanı ve disk olur. Sınırı dikey ölçeklemedir ve tek hata noktasıdır: sunucu düşerse her şey düşer. Yedek, izleme ve geri yükleme planı şarttır.

Başka çözüme geçme zamanı geldi mi?

• Veritabanı bağlantı hataları ya da zaman aşımları görüyorsun.
• Soğuk başlatma gecikmesi kullanıcıyı rahatsız ediyor.
• Fatura trafikle orantısız büyüyor.
• Bir platformun sert limitine (depolama, işlem süresi, eşzamanlılık) dayandın.
• Gereksinimler platformun sunduklarını aştı (özel ağ, uyumluluk, özel altyapı).

İşaretler yoksa taşımayın. Önce ölçün: gerçek sorun çoğu zaman bir indeks ya da önbellektir.