Neon vs PlanetScale vs Turso: Edge'de Postgres, MySQL mı SQLite mi?

Neon, PlanetScale ve Turso arasındaki karar, üç temelden farklı seçeneğe dayanıyor: Postgres, MySQL/Vitess ve edge'de SQLite. Geçen yıl içinde tablo dramatik biçimde değişti -- Databricks Neon'u yaklaşık 1 milyar dolara satın aldı, PlanetScale Postgres desteğini başlattı ve Turso scale-to-zero özelliğini kullanımdan kaldırdı. 2026'da sunucusuz bir veritabanı seçiyorsanız, muhtemelen okuduğunuz her karşılaştırma güncelliğini yitirmiştir.

Neon vs PlanetScale vs Turso Bir Bakışta

Tam Postgres uyumluluğu, cömert bir ücretsiz katman ve en iyi Vercel entegrasyonu istiyorsanız Neon'u seçin. Yatay sharding ile kurumsal ölçekte MySQL'e ihtiyaç duyuyorsanız PlanetScale'i seçin. Edge gecikmesi ve kullanıcı başına veritabanı mimarileri en önemli önceliğinizse Turso'yu seçin.

Bu kısa versiyondu. Makalenin geri kalanı her satırın neden böyle göründüğünü tam olarak açıklıyor.

Her Veritabanı Altyapıda Nasıl Çalışır?

Her platformun altındaki motor, sorgu sözdiziminden ölçekleme sınırlarına kadar her şeyi belirler. Mimariyi anlamak, uygulamanız büyüdükçe her birinin nasıl davranacağını tahmin etmenize yardımcı olur.

Neon: Branching ile Sunucusuz Postgres

Neon, compute'u depolamadan tamamen ayırır. Postgres compute düğümleriniz geçicidirler -- bir sorgu geldiğinde başlar, boşta kaldığında aşağı iner (veya sıfıra iner). Depolama, dayanıklılık ve point-in-time kurtarma işlemlerini yöneten ayrı bir pageserver katmanında bulunur.

Bu mimari, Neon'un en güçlü özelliğini mümkün kılıyor: copy-on-write branching. Boyuttan bağımsız olarak bir veritabanı dalı oluşturmak anlık denecek kadar hızlıdır; çünkü veri kopyalanmaz -- depolama sayfaları üst öğeyle paylaşılır ve veriler değiştiğinde yalnızca yeni sayfalar yazılır. Veritabanınız için git branch komutunu düşünün.

• Tam PostgreSQL wire protokolü (pg_dump, psql, her şey çalışır)
• 0,25'ten 56 CU'ya otomatik ölçeklendirme compute
• PgBouncer üzerinden yerleşik bağlantı havuzlama
• Neon'un mimarisi, write-ahead log dayanıklılığı için safekeepers kullanır

PlanetScale: Vitess Destekli MySQL (ve Artık Postgres)

PlanetScale, Vitess üzerinde çalışır; bu MySQL kümeleme motoru, YouTube'da binlerce düğüm üzerinde veri tabanını parçalara ayırmak için geliştirilmiştir. MySQL için yatay ölçeklemeye ihtiyaç duyuyorsanız, Vitess mevcut en savaş testinden geçmiş çözümdür.

PlanetScale'in imza DX özelliği deploy requests'tir -- özünde şema değişiklikleri için pull request'ler. Bir geçiş öneriyor, diff'i inceliyor ve sıfır kesinti süresiyle uyguluyorsunuz. Kilit yok, bakım penceresi yok.

Eylül 2025'ten itibaren PlanetScale, yönetilen Postgres da sunuyor. Bu, Vitess tekliflerinden farklı bir ürün -- aylık 200 ₺'den başlayan tek düğümlü Postgres veritabanları. Postgres için yatay sharding ("Neki" adı verilen) hâlâ geliştirme aşamasındadır.

Postgres'in MySQL'den ne zaman daha mantıklı olduğuna (ve tam tersi) daha ayrıntılı bakmak için PostgreSQL vs MySQL karşılaştırmamıza göz atın.

• Vitess: yatay sharding, sıfır kesintili şema geçişleri
• Postgres: tek düğüm, üretime hazır, ancak henüz sharding yok
• Güvenli ve incelenebilir şema değişiklikleri için deploy requests
• Scale-to-zero yok -- veritabanları her zaman çalışır

Turso: libSQL ile Edge'de SQLite

Turso tamamen farklı bir yaklaşım benimsiyor. Sunucu tabanlı bir veritabanı çalıştırmak yerine, sunucu modu özelliklerine sahip SQLite'ın açık kaynaklı bir çatalı olan libSQL'i kullanıyor. Verileriniz edge'de, kelimenin tam anlamıyla uygulamanızın çalışma zamanına gömülü biçimde yaşayabilir.

Temel kavram gömülü replikalardır: uygulama sürecinizin içinde (veya edge konumlarında) sıfır ağ gecikmesiyle okuma yapan okuma replikaları. Yazma işlemleri birincil bir örneğe gider ve replikalar için eşzamansız olarak yayılır.

• libSQL, SQLite'ı HTTP erişimi, çoğaltma ve çok kiracılılık özellikleriyle genişletir
• Kullanıcı başına veritabanı modeli binlerce yalıtılmış veritabanını destekler
• Yazma işlemleri milisaniyeler içinde birincilden replikalara yayılır
• Okuma yoğun, küresel olarak dağıtılmış uygulamalar için ideal

Karar: Mimari genişlik açısından Neon kazanıyor. Anında branching ile tam Postgres, en geniş kullanım durumlarını kapsıyor. PlanetScale, özellikle Vitess düzeyinde yatay sharding'e ihtiyaç duyuyorsanız kazanıyor. Turso, edge'de veriye ihtiyaç duyuyorsanız kazanıyor.

Performans ve Gecikme Açısından Nasıl Karşılaştırılırlar?

Performans, geliştiricilerin ilk sorduğu sorudur ve yanıt tamamen veritabanınızın sıcak mı yoksa soğuk mu olduğuna bağlıdır.

Cold Start Gerçeklik Kontrolü

Neon, varsayılan olarak hâlâ scale-to-zero yapan üç veritabanından tek olanıdır. Compute düğümünüz boşta kalma durumundan uyandığında, ilk sorguda 400-750 ms bekleyin. Sonraki sorgular hızlıdır. Minimum compute boyutu ayarlayarak cold start'ları ortadan kaldırabilirsiniz (0,25 CU yaklaşık 200 ₺/ay).

PlanetScale her zaman her zaman açık olmuştur -- cold start yok, nokta. Veritabanınız birisi sorgu yapsa da yapmasada çalışır.

Turso, Ocak 2025'te yeni kullanıcılar için scale-to-zero'yu kullanımdan kaldırdı. Yeni kayıtlar her zaman açık örnekler alıyor; bu da cold start olmadığı anlamına geliyor ama "boştayken hiçbir şey ödememe" tasarrufu da yok.

Edge Gecikmesi: Turso'nun Parladığı Yer

Sıcak sorgular için üçü de hızlıdır. Ancak Turso'nun gömülü replikaları, diğer ikisinin sunamayacağı bir şey sunuyor: edge'de tek haneli milisaniye okumalar. SQLite replikası, kodunuzla aynı Cloudflare Worker veya Vercel Edge Function içinde yaşadığında okumalar için hiç ağ atlaması olmaz.

Pilcrow'dan benchmark verileri (Temmuz 2023 -- güncel değil, yön gösterici olarak değerlendirin), merkezi sorgular için PlanetScale HTTP'yi ~8 ms, Neon HTTP'yi ~5 ms ve Turso HTTP'yi ~27 ms olarak gösterdi. Bu rakamlar PlanetScale'in Postgres lansmanından ve Turso'nun altyapı değişikliklerinden önceye ait, bu yüzden kesin sonuç değil referans noktası olarak alın.

Karar: Edge gecikmesinde Turso kazanıyor. Sıfır ağ atlayışlı okumalarla gömülü replikalar eşsiz. Cold start endişesi olmayan merkezi iş yükleri için PlanetScale'in her zaman açık tutarlılığı geçilmesi zor. Neon'un cold start'ları, scale-to-zero tasarrufu için yapılan ödünleşimdir.

Her Veritabanı Gerçekte Ne Kadara Mal Olur?

Çoğu karşılaştırmanın yetersiz kaldığı yer burası -- gerçek bir uygulamanın ne ödeyeceğini hesaplamadan plan fiyatlarını listeliyorlar. Bunu düzeltelim.

Ücretsiz Katman Özeti

PlanetScale, Nisan 2024'te ücretsiz Hobby katmanını kaldırdı. En ucuz giriş noktası artık tek düğümlü Postgres veritabanı için aylık 200 ₺. Vitess/MySQL veritabanları için fiyatlandırma küme tabanlı ve önemli ölçüde daha yüksektir.

Dört Ölçek Kademesinde Gerçek Aylık Maliyet

Bu tahminler, her platformun resmi fiyatlandırma sayfalarından 2026 güncel fiyatlarını kullanır. Gerçek maliyetler kullanım düzenlerine göre değişir.

Birkaç şey dikkat çekiyor. Turso, satır okuma fiyatlandırma modelinin okuma yoğun uygulamaları desteklemesi nedeniyle düşük ve orta kademelerde oldukça ucuz. Neon'un kullanım bazlı fiyatlandırması, yalnızca tükettiğiniz için ödeme yaptığınız anlamına geliyor -- ücretsiz kademede boşta kalan veritabanlarının maliyeti yok. PlanetScale'in fiyatlandırması Postgres tek düğümleri için rekabetçi ancak Vitess kümeleriyle tırmanıyor.

PlanetScale Fiyat Uçurumu

PlanetScale'in solo geliştiriciler için en büyük zayıflığı: ücretsiz katman yok. 0 ₺'den (bir rakip kullanarak) en az 200 ₺/ay'a geçiyorsunuz. Fonlanmış girişimler için bu önemsiz, ancak yan projeler ve prototip geliştirme için Neon ve Turso'nun ücretsiz katmanları anlamlı ölçüde daha iyi.

Öte yandan PlanetScale'in Vitess teklifi, ne Neon'un ne de Turso'nun eşleşemeyeceği yatay sharding sağlıyor. Yazma hacminiz sharding gerektiriyorsa, prim haklıdır.

Karar: Çoğu bütçe için Neon kazanıyor. Ücretsiz katman artı kullanım bazlı fiyatlandırma en esnek modeldir. Turso'nun satır okuma fiyatlandırması okuma yoğun uygulamalar için mükemmel. PlanetScale alt uçta daha pahalı ama kurumsal düzeyde ölçeklendirme sunuyor.

Geliştirici Deneyimi Nasıl?

Günlük DX, benchmark rakamlarından daha önemlidir. İşte üçünün gerçekten kullanacağınız özelliklerde karşılaştırması.

Veritabanı Branching ve CI/CD

Neon'un copy-on-write branching'i altın standarttır. Her PR için bir dal oluşturun, geçişleri karşı çalıştırın, üretim benzeri verilerle test edin ve birleştirin. Vercel entegrasyonu, her önizleme dağıtımı için otomatik olarak bir dal oluşturur.

PlanetScale'in deploy request'leri aynı fikrin farklı bir çeşididir. Tüm veritabanını dallandırmak yerine şemayı dallandırıyorsunuz. Bir geçiş önerin, diff'i inceleyin ve sıfır kesinti süresiyle uygulayın. Daha fikir belirleyicidir ama ölçekte şema değişiklikleri için tartışmasız daha güvenlidir.

Turso'nun branching özelliği yoktur. Geçişleri standart SQLite araçlarıyla yönetiyorsunuz.

ORM Uyumluluk Matrisi

Neon ve PlanetScale'in Postgres teklifi, tüm Postgres ORM ekosistemiyle kutudan çıkar çıkmaz çalışır. Turso, iyi bakımlı ancak daha dar olan libSQL'e özgü adaptörler gerektirir.

CLI ve Yerel Geliştirme

Üçü de sağlam CLI'lara sahip: Neon için neonctl, PlanetScale için pscale ve Turso için turso. Her biri veritabanı oluşturmayı, dalları yönetmeyi (uygulanabilir olduğunda) ve terminalden bağlanmayı destekler.

Yerel geliştirme için Neon dalları parlıyor -- üretime dokunmadan üretim verilerini yansıtan bir dala karşı geliştirme yapabiliyorsunuz. PlanetScale'in geliştirme dalları benzer bir amaca hizmet eder. Turso, SQLite'ı yerel olarak çalıştırır, bu yüzden yerel geliştirme son derece basit -- sadece yerel bir .db dosyasına işaret edin.

Karar: Geliştirici deneyiminde Neon kazanıyor. Vercel entegrasyonuyla copy-on-write branching en iyi CI/CD hikayesidir. PlanetScale'in deploy request'leri şema düzeyinde inceleme isteyen ekipler için mükemmeldir. Turso'nun sadeliği hafife alınıyor ama branching eksikliği var.

Next.js'ten Bağlanma -- Yan Yana Kod

İşte bir Next.js API rotasından veya Server Component'ten her veritabanına bağlanmanın nasıl göründüğü. Bunlar kopyala-yapıştır'a hazır.

Ham Sürücü Bağlantısı (Üçü de)

@neondatabase/serverless ile Neon:

// lib/neon.ts
import { neon } from "@neondatabase/serverless";

const sql = neon(process.env.DATABASE_URL!);

// Edge Runtime ve Node.js'de çalışır
export async function getActiveUsers() {
  const users = await sql`
    SELECT * FROM users WHERE active = true
  `;
  return users;
}

@planetscale/database ile PlanetScale:

// lib/planetscale.ts
import { connect } from "@planetscale/database";

const conn = connect({
  host: process.env.DATABASE_HOST,
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
});

// Edge Runtime ve Node.js'de çalışır
export async function getActiveUsers() {
  const results = await conn.execute(
    "SELECT * FROM users WHERE active = true"
  );
  return results.rows;
}

@libsql/client ile Turso:

// lib/turso.ts
import { createClient } from "@libsql/client";

const turso = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN,
});

// Edge Runtime ve Node.js'de çalışır
export async function getActiveUsers() {
  const result = await turso.execute(
    "SELECT * FROM users WHERE active = 1"
  );
  return result.rows;
}

Turso'nun = true yerine = 1 kullandığına dikkat edin -- SQLite'ın yerel boolean türü yoktur. Küçük bir fark, ama insanları şaşırtıyor.

Drizzle ORM Kurulumu (Üçü de)

Drizzle kullanıyorsanız (ve tip güvenli sorgular için muhtemelen kullanmalısınız), her biri için yapılandırma şöyle:

// drizzle.config.ts — Neon
import { neon } from "@neondatabase/serverless";
import { drizzle } from "drizzle-orm/neon-http";

const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql);

// drizzle.config.ts — PlanetScale (MySQL/Vitess)
import { connect } from "@planetscale/database";
import { drizzle } from "drizzle-orm/planetscale-serverless";

const connection = connect({
  host: process.env.DATABASE_HOST,
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
});
export const db = drizzle(connection);

// drizzle.config.ts — Turso
import { createClient } from "@libsql/client";
import { drizzle } from "drizzle-orm/libsql";

const turso = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN,
});
export const db = drizzle(turso);

Her üç sürücü de Vercel Edge Functions ve Cloudflare Workers'da çalışır. API yüzeyi, aralarında geçiş yapmanın büyük ölçüde bir sürücü değişimi olduğu kadar benzer -- Drizzle şemanız ve sorgularınız aynı kalır (SQL diyalekti farklılıkları hariç).

Birden Fazla Sunucusuz Veritabanı Birlikte Kullanılabilir mi?

İşte toplulukta ivme kazanan ama hiçbir karşılaştırma makalesinin bahsetmediği bir desen: edge okumaları için Turso ve yazmalar için Neon kullanmak.

Fikir basit. Birincil verileriniz Neon'da yaşar (tam Postgres, güçlü tutarlılık, zengin sorgu desteği). Okuma yoğun verileri, kullanıcılarınıza küresel olarak yakın olan Turso edge replikalarına kopyalarsınız. Okumalar milisaniyenin altında gecikmeyle Turso'ya ulaşır; yazmalar dayanıklılık ve tutarlılık için Neon'a gider.

Bu ne zaman mantıklı:

• Okuma gecikmesinin önemli olduğu küresel olarak dağıtılmış uygulamalar (gösterge panelleri, içerik platformları)
• Her kiracının okuma yoğun verilerinin edge önbelleklemesinden yararlandığı çok kiracılı SaaS
• Biraz eski okumaları tolere edebildiğiniz 90/10 okuma/yazma oranına sahip uygulamalar

Ne zaman atlayacaksınız:

• Çoğu uygulama 10 ms altında küresel okumaya ihtiyaç duymaz -- tek bölgeli bir Neon örneği yeterlidir
• İki veritabanını bakımda tutmanın, veri senkronizasyonunun ve hata yönetiminin karmaşıklığı gerçektir
• Uygulamanız yazma yoğunsa, edge okumaları pek yardımcı olmaz

Kendinize karşı dürüst olun: katı gecikme gereksinimleri olan küresel ölçekte çalışmıyorsanız, bu anlamlı bir fayda olmaksızın karmaşıklık ekler. Ama ihtiyaç duyan uygulamalar için gerçekten zarif bir desendir.

2025-2026'da Ne Değişti? (Üç Büyük Sarsılma)

Her rakip karşılaştırması bu olaylardan önce yazıldı. İşte ne değişti ve bugün kararınız için ne anlama geliyor.

Neon + Databricks: 1 Milyar Dolarlık Satın Alma Ne Anlama Geliyor?

Mayıs 2025'te Databricks, Neon'u yaklaşık 1 milyar dolara satın aldı. Bu sadece finansal bir olay değildi -- Neon'un yönünü değiştirdi.

Anlık etki: Neon, depolama maliyetlerini %80 düşürdü (GB-ay başına 1,75 dolardan 0,35 dolara). Vantage analizi, bunun kısmen Databricks'in AWS hacim indirimlerinin Neon müşterilerine yansımasından kaynaklandığını gösteriyor.

Stratejik sinyal: Databricks, Neon veritabanlarının %80'inin artık yapay zeka ajanları tarafından oluşturulduğunu belirtti; bu oran GA'da %30'du. Neon kendini yapay zeka güdümlü geliştirme için varsayılan veritabanı olarak konumlandırıyor -- otomatik şema oluşturma, ajan yönetimli veriler, programatik veritabanı provizyon.

Bir geliştirici olarak sizin için satın alma şu anlama geliyor: daha ucuz fiyatlandırma, kurumsal destek (Databricks kârlı) ve giderek programatik/yapay zeka iş akışları için optimize edilen bir yol haritası.

PlanetScale Postgres: MySQL Artık Tek Seçenek Değil

Eylül 2025'te PlanetScale, Postgres desteğini GA olarak başlattı. Bu, eski "Neon = Postgres, PlanetScale = MySQL" çerçevesini tamamen değiştiriyor.

PlanetScale Postgres, Query Insights, şema önerileri ve branching gibi özelliklerle tek düğümlü veritabanları için aylık 200 ₺'den başlıyor. Üretim için hazır ve zaten yüzlerce şirkette çalışıyor. Ancak Postgres için yatay sharding ("Neki" projesi) hâlâ geliştirme aşamasındadır.

Bu ne anlama geliyor: Tamamen motor tercihine göre Neon'a karşı PlanetScale arasında seçim yapıyorsanız, PlanetScale artık her ikisini de kapsıyor. Ama Neon'un Postgres'i daha olgunlaşmış (ilk günden beri Postgres yerel), ücretsiz katmanı var ve copy-on-write semantiğiyle daha derin branching sunuyor. PlanetScale Postgres'i takip etmeye değer ama Neon Postgres tarafında hâlâ önde.

Turso Scale-to-Zero'yu Bırakıyor: Varsayılan Olarak Always-On

Ocak 2025'te Turso önemli platform değişiklikleri duyurdu: yeni kullanıcılar için scale-to-zero kullanımdan kaldırıldı, altyapı AWS'ye konsolide edildi ve yeni kayıtlar için edge replikaları durduruldu.

Ödünleşim açık: artık cold start yok (iyi), ama artık "boştayken ücretsiz" tasarrufu da yok (pek iyi değil). Legacy planlardaki mevcut kullanıcılar scale-to-zero'yu koruyor ama diğer herkes always-on örnekler alıyor.

Bu Turso'yu daha öngörülebilir kılıyor -- cold start gecikmesiyle sürpriz yaşamazsınız -- ama aynı zamanda Turso ile PlanetScale arasındaki "sunucusuz" boyutundaki uçurumu da daraltıyor. İkisi de artık always-on yönetilen veritabanları; Turso'nun edge hikayesi onu farklılaştıran şey.

Neon vs PlanetScale vs Turso: Hangisini Seçmelisiniz?

Yeterli analiz. İşte karar çerçevesi.

2026'da yeni bir proje başlatan çoğu geliştirici için Neon varsayılan seçimdir. Ücretsiz katman, tam Postgres, anında branching ve Vercel entegrasyonu, kullanım durumlarının %80'ini karşılıyor. Her zaman ücretli planlara ölçekleyebilir veya sonra geçiş yapabilirsiniz -- Postgres ekosistemi hiçbir zaman kilitli kalmayacağınız anlamına geliyor.

PlanetScale, kurumsal ölçekte MySQL'e ihtiyaç duyduğunuzda veya büyük ekiplerde sıfır kesintili şema değişiklikleri için deploy request iş akışını istediğinizde hakkını kazanıyor.

Turso, mimarinizin edge öncelikli veri erişimi veya ölçekte çok kiracılı veritabanı izolasyonu gerektirdiğinde doğru seçimdir. Özelleşmiş bir araçtır ve uzmanlaştığı konuda mükemmeldir.

Techsy Sunucusuz Veritabanı Seçimine Nasıl Yaklaşıyor?

Her müşteri projesi için sunucusuz veritabanlarını dört boyutta değerlendiriyoruz: veri modeli karmaşıklığı, ekip büyüklüğü ve SQL diyalekti tercihi, önümüzdeki 12-18 ay içindeki ölçekleme yörüngesi ve dağıtım platformu (Vercel, Cloudflare, AWS vb.).

Çoğu proje için varsayılan yığınımız Neon + Drizzle + Next.js. Nedeni şu:

1. Postgres bize en zengin ekosistemi veriyor -- JSON sütunları, tam metin arama, PostGIS, uzantılar
2. Neon'un branching'i önizleme dağıtımlarına ve CI pipeline'larına mükemmel biçimde uyuyor
3. Ücretsiz katman, erken aşama müşteriler için faturalama yükü olmadan prototip yapmamıza olanak tanıyor
4. Drizzle'ın tip güvenliği, şema sapmasını üretime ulaşmadan önce tespit ediyor

Alternatifleri ne zaman öneriyoruz:

• Sorguları yeniden yazmak pratik olmayan mevcut MySQL altyapısından geçiş yapan ekipler için PlanetScale
• Edge gecikmesinin ölçülebilir bir iş metriği olduğu küresel dağıtılmış, okuma yoğun ürünler geliştiren müşteriler için Turso
• Bazen dürüst cevap "sadece Supabase kullanın"dır; tek bir yönetilen pakette auth + veritabanı + depolama istediğinizde

Bir sonraki projeniz için doğru veritabanını seçmenize yardımcı olmamızı ister misiniz? Ücretsiz backend danışmanlığı alın.

SSS

Neon, PlanetScale'den Daha mı İyi?

İhtiyaçlarınıza bağlı. Neon, Postgres yerel ekipler için daha iyi, ücretsiz katman sunuyor ve copy-on-write semantiğiyle daha derin veritabanı branching'e sahip. PlanetScale, Vitess sharding ve sıfır kesintili deploy request'lerle kurumsal ölçekte MySQL iş yükleri için daha iyi. PlanetScale artık Postgres da sunduğu için fark kapanıyor -- ama Neon'un Postgres'i daha olgun.

Neon ile Turso Arasındaki Fark Nedir?

Neon, compute-depolama ayrımı ve anında branching ile sunucusuz PostgreSQL'dir. Turso, edge okumaları için gömülü replikalarla SQLite tabanlıdır (libSQL). Tam Postgres ekosistemi ve branching iş akışları için Neon'u seçin. Küresel düşük gecikmeli okumalar ve kullanıcı başına veritabanı çok kiracılı mimariler için Turso'yu seçin.

Ücretsiz Katman Olmadan PlanetScale Hâlâ Değer mi?

Hobi projeleri için muhtemelen değil -- Neon ve Turso'nun ikisi de cömert ücretsiz katmanlar sunuyor. Vitess destekli yatay sharding veya sıfır kesintili deploy request'lere ihtiyaç duyan fonlanmış girişimler ve kurumlar için PlanetScale'in fiyatlandırması haklıdır. 200 ₺/aylık Postgres giriş noktası rekabetçi, ancak ücretsiz değil.

Next.js İçin En İyi Sunucusuz Veritabanı Nedir?

Çoğu geliştirici için Neon. En derin Vercel entegrasyonuna sahip (önizleme dağıtımı başına dal), tüm Postgres ORM'leriyle çalışıyor ve ücretsiz başlıyor. Özellikle küresel edge okumaları ihtiyacınız varsa Turso tercih edilir. Her üçünün de Vercel Edge Functions'da çalışan sürücüleri var.

Neon'un Cold Start'ları Üretimde Ne Kadar Kötü?

Compute boşta kalma durumundan uyandığında ilk sorguda 400-750 ms bekleyin. Sonraki sorgular hızlıdır (tek haneli ms). Her zaman duyarlı uygulamalar için, örneği sıcak tutmak ve cold start'ları tamamen ortadan kaldırmak amacıyla minimum compute'u 0,25 CU'ya (Launch planında yaklaşık 200 ₺/ay) ayarlayın.

PlanetScale Artık PostgreSQL Kullanabiliyor mu?

Evet, Eylül 2025'ten beri. PlanetScale, aylık 200 ₺'den başlayan tek düğümlü veritabanlarıyla PostgreSQL desteğini GA olarak başlattı. Yüzlerce şirketle üretim için hazır. Ancak Postgres için yatay sharding hâlâ geliştirme aşamasındadır -- bunun için Vitess/MySQL tekliflerine ihtiyaç duyacaksınız.

Turso Üretim Uygulamaları İçin İyi mi?

Evet, uyarılarla. Turso, okuma yoğun iş yüklerinde ve çok kiracılı mimarilerde mükemmel. Yazma eşzamanlılığı önemli ölçüde iyileşti. Yüksek okuma-yazma oranlarına ve küresel dağıtım gereksinimlerine sahip uygulamalar için en uygunudur. Yazma yoğun işlemsel iş yükleri için Neon veya PlanetScale daha iyi seçimlerdir.

PlanetScale'in Ücretsiz Katmanına Ne Oldu?

PlanetScale, Hobby (ücretsiz) katmanını Nisan 2024'te kaldırdı. Yeni Hobby veritabanları 6 Mart 2024'te engellendi ve mevcut olanların tümü 8 Nisan 2024'te kaldırıldı. En ucuz giriş noktası artık Postgres tek düğümlü veritabanı için aylık 200 ₺. Bu, birçok solo geliştiricinin Neon veya Turso'ya geçmesine yol açtı.

Databricks Satın Alması Neon'u Nasıl Etkiliyor?

Databricks, Mayıs 2025'te Neon'u yaklaşık 1 milyar dolara satın aldı. O zamandan beri Neon depolama maliyetlerini %80 düşürdü, yapay zeka ajan iş akışlarına yatırım yaptı ve kurumsal güvenilirlik kazandı. Fiyatlar ucuzladı, pahalanmadı. Satın alma, uzun vadeli istikrara işaret ediyor -- Databricks kârlı ve Neon'u Postgres katmanı olarak kullanmaya kararlı.

Turso Hâlâ Scale-to-Zero'yu Destekliyor mu?

Turso, 2025 başında yeni kullanıcılar için scale-to-zero'yu kullanımdan kaldırdı. Legacy planlardaki mevcut kullanıcılar bunu koruyor ama yeni kayıtlar always-on örnekler alıyor. Bu cold start'ları ortadan kaldırır ama "boştayken ödeme yapma" avantajını da kaldırır. Edge replikaları da platform konsolidasyonunun bir parçası olarak yeni kullanıcılar için durduruldu.

Bir Yan Proje İçin Hangi Sunucusuz Veritabanı En Ucuz?

Neon ve Turso'nun ikisi de çoğu yan projeyi karşılayan ücretsiz katmanlar sunuyor. Neon size 0,5 GB depolama ve 100 compute saati veriyor. Turso size 5 GB depolama ve 500 milyon satır okuma veriyor. PlanetScale'in ücretsiz katmanı yok -- minimum aylık 200 ₺. Hafif trafiğe sahip tipik bir yan proje için herhangi bir ücretsiz katman fazlasıyla yeterli.

Nihai Karar

2026'da çoğu geliştirici için Neon, başlamak için en iyi sunucusuz veritabanıdır. Size tam Postgres ekosistemi, gerçek projeler için gerçekten işe yarayan ücretsiz bir katman, CI/CD için anında branching ve kullanımla ölçeklenen fiyatlandırma sunuyor. Databricks desteği, kurumsal kilitlenme olmadan kurumsal istikrar ekliyor.

PlanetScale, yatay MySQL sharding'e ihtiyaç duyduğunuzda veya ekibiniz zaten MySQL ekosistemine yatırım yapmışsa hakkını kazanıyor. Turso, edge gecikmesi ölçülebilir bir gereksinim olduğunda -- sadece güzel bir ek özellik değil -- doğru seçimdir.

Veri modelinizi, ölçekleme yörüngenzii ve kullanıcılarınızın nerede olduğunu değerlendirin. Ardından birini seçin ve inşa etmeye başlayın -- her üçü de üretim için hazır, ve Postgres/MySQL/SQLite ekosistemi hiçbir zaman gerçekten kilitli kalmayacağınız anlamına geliyor.

Kaynaklar

• Neon Mimari Genel Bakış
• Neon Fiyatlandırma
• PlanetScale Fiyatlandırma
• PlanetScale for Postgres GA'ya Çıktı
• Turso Fiyatlandırma
• Turso libSQL Belgeleri
• Databricks Neon'u Satın Almayı Kabul Ediyor
• Turso Platformunda Yaklaşan Değişiklikler
• PlanetScale Hobby Planını Kullanımdan Kaldırıyor
• Sunucusuz Veritabanı Gecikme Kıyaslamaları -- Pilcrow (2023)
• Drizzle ORM -- Turso Bağlantısı