2026 itibarıyla TypeScript ekosisteminde veritabanı erişimi için üç isim öne çıkıyor: Drizzle, Prisma ve Kysely. drizzle vs prisma tartışmasının kısa cevabı şu: Prisma, deklaratif şema ve geniş eklenti yüzeyiyle hızlı başlangıç ve büyük ekipler için olgun; Drizzle, SQL’e yakın tip güvenli sorgu zinciri ve düşük çalışma zamanı maliyetiyle edge/serverless senaryolarda öne çıkıyor; Kysely ise saf bir query builder olarak migration veya ORM dayatması olmadan tam SQL kontrolü sunuyor. GitHub yıldız sayıları (Drizzle ≈24k, Prisma ≈39k, Kysely ≈11k — kasım 2025 itibarıyla) ve npm haftalık indirme verileri, üç projenin de aktif kullanımda olduğunu gösteriyor; seçim artık “hangisi popüler” değil, “hangisi sizin runtime, ekip ve veri modeli profilinize uyuyor” sorusudur. Bu yazı, üç aracı runtime davranışı, type inference modeli, migration disiplini, performans ve maliyet açılarından kıyaslıyor; ayrıca Node.js 22, Bun 1.2 ve Cloudflare Workers gibi modern çalışma ortamlarındaki davranış farklarına giriyor.
TypeScript ile SQL kullanmanın 2020–2022 dönemindeki ana acısı, “type drift” idi: kod tarafında tanımladığınız tipler ile veritabanındaki gerçek şema arasındaki sapma. Üç araç da bu problemi farklı katmanlardan çözüyor. Prisma kendi DSL’iyle (schema.prisma) tek doğruluk kaynağı (single source of truth) yaklaşımını benimserken Drizzle, TypeScript dosyalarını şema kaynağı olarak kabul eder; Kysely ise şemayı tamamen sizin tanımlamanıza bırakır ve yalnızca bu tipler üzerinden SQL üretir. Bu mimari fark, sürdürebilirlik, code review yükü ve onboarding süresini doğrudan etkiler.
2026’da TypeScript veritabanı katmanı: kısa manzara
Stack Overflow Developer Survey 2024’e göre TypeScript, profesyonel geliştiriciler arasında %38’in üzerinde kullanım payına ulaştı; bu oran 2020’deki %25 seviyesinin yaklaşık 1,5 katı. Backend tarafında Node.js 22 LTS, Deno 2 ve Bun 1.2’nin paralel olgunlaşması, “tek runtime varsayımı” döneminin sonu anlamına geliyor. Bir veritabanı kütüphanesinin 2026’da kabul edilebilir olması için: (a) Node, Bun ve workerd üzerinde çalışması, (b) tree-shaking sonrası kabul edilebilir bundle boyutu, (c) ESM-first dağıtım ve (d) gerçek tip güvenliği sağlaması gerekiyor.
Bu üç araç da birinci kriteri karşılıyor; ikinci ve üçüncüde belirgin farklar var. Aşağıdaki tablo, üçünün üst düzey kimlik kartını veriyor.
| Özellik | Drizzle ORM | Prisma | Kysely |
|---|---|---|---|
| Kategori | SQL-first lite ORM | Full ORM + DSL | Pure Query Builder |
| İlk sürüm | 2022 | 2019 (v1) | 2022 |
| Şema kaynağı | TypeScript dosyası | schema.prisma DSL | TypeScript interface |
| Runtime motor | Yok (pure JS/TS) | Query Engine (Rust, opsiyonel) | Yok (pure JS/TS) |
| Migration aracı | drizzle-kit | prisma migrate | kysely-migration-cli (3rd party) |
| Bundle boyutu (min+gz) | ~30 KB | ~200 KB+ (engine hariç) | ~15 KB |
| Edge/Workers desteği | Tam | Driver Adapters ile | Tam |
| SQL kontrolü | Yüksek | Orta (raw escape hatch) | Çok yüksek |
| Lisans | Apache 2.0 | Apache 2.0 | MIT |
Bu tablonun anahtarı “Runtime motor” satırıdır. Prisma uzun yıllar boyunca Rust ile yazılmış ayrı bir Query Engine binary’si gönderiyordu; bu, deployment boyutunu büyütüyor ve serverless cold-start’ları olumsuz etkiliyordu. 2024–2025 sürümleriyle Prisma, “Driver Adapters” ve prisma-client + pg kombinasyonuna geçiş başlatarak bu sorunu hafifletti. Yine de Drizzle ve Kysely, kuruluştan bu yana “pure JS” felsefesiyle bu yükten muaf.
Mimari farklılıklar: ORM, lite ORM ve query builder
Üç aracı aynı şemsiye altına koymak yanıltıcıdır. Her biri, sorumluluk sınırını farklı yere çiziyor:
- Prisma — Full ORM yaklaşımı: Veritabanı modeli, ilişki tanımları, migration üretimi, client API üretimi ve hatta seed komutu tek bir CLI altında toplanıyor. Avantaj: tek tutarlı zihinsel model, dokümantasyon konsantrasyonu. Dezavantaj: kendi DSL’i öğrenme yükü, “leaky abstraction” anlarında raw SQL’e düşme.
- Drizzle — SQL-first lite ORM: TypeScript ile yazılan şema, hem tip kaynağı hem de SQL üreten builder‘ın temeli. Avantaj: SQL’e yakın söz dizimi, sıfır runtime motor, tree-shake dostu. Dezavantaj: ilişki sorguları için iki API var (Relations API + standart join), öğrenme eğrisi başlangıçta dağınık.
- Kysely — Saf Query Builder: ORM iddiası yok; sadece tip güvenli SQL üretir. Migration için ayrı paket gerekir, ilişkileri siz yazarsınız. Avantaj: maksimum kontrol, minimum sürpriz. Dezavantaj: boilerplate fazla, “her şeyi kendin yap” felsefesi küçük ekipte yavaşlatır.
Bu üçlü, aslında 2010’larda Java dünyasında yaşanan Hibernate vs MyBatis vs JDBC Template tartışmasının TypeScript karşılığı olarak okunabilir. Tarihsel paralelliği önemseyenler için Java 21 Virtual Threads yazımız Java tarafındaki paralel evrimi anlatıyor; SQL erişim katmanı tartışmasında dil değişse de örüntüler benzer kalıyor.
Tip güvenliği: nereden geliyor ve ne kadar derin?
“Type-safe SQL” ifadesi üç araçta üç farklı şey ifade ediyor. Karşılaştırma matrisi:
| Tip güvenliği boyutu | Drizzle | Prisma | Kysely |
|---|---|---|---|
| Column adı tipli mi? | Evet | Evet | Evet |
| SELECT projection tipli mi? | Evet (inferred) | Evet (generated) | Evet (inferred) |
| JOIN sonrası tablo birleşimi | Tipli | Tipli (include/select) | Tipli (manuel) |
| Raw SQL içinde parametre | Tagged template | $queryRaw + Tagged | sql tagged template |
| Compile-time SQL doğrulaması | Yarı (yapı) | Yarı (Prisma DSL) | Yüksek (yapı + alias) |
| Şema değişiminde derleme hatası | Evet (yeniden generate) | Evet (prisma generate) | Evet (manuel sync) |
| Aggregate fonksiyonların tipi | Number/Bigint ayırımı | Sabit dönüş | İnce ayar mümkün |
Drizzle, “şema TypeScript’in kendisi” prensibiyle pgTable("users", { id: serial("id").primaryKey(), email: text("email").notNull() }) gibi tanımlar üretir. Bu tanımlar üzerinden db.select().from(users).where(eq(users.email, "x")) ifadesi doğrudan satır tipini çıkarır. Prisma’da ise prisma generate komutu, schema.prisma dosyasından .prisma/client klasörüne bir generated client yazar; bu client’ın türleri proje boyunca paylaşılır. Kysely en katı çizgide: interface DB { user: UserTable; post: PostTable } şeklinde manuel tanım yaparsınız, ardından db.selectFrom("user").select(["id","email"]) ifadesi tipler üzerinden doğrulanır.
Pratik fark şudur: refactor anında hangi araç sizi koruyor? Bir kolon adını değiştirdiğinizde Drizzle ve Prisma, generate adımı sonrası derleme hatası verir; Kysely’de ise migration ile interface’i senkron tutmak sizin sorumluluğunuzdadır. Eğer bu disiplin ekip dışından sağlanamıyorsa, Kysely’nin sunduğu özgürlük ters tepebilir. Python tarafında mypy / pyright disiplini ile TypeScript’in strict ayarı arasındaki benzer öğretiler burada da geçerli: yapı kontrolü, niyet kontrolünün yerini tutmaz.
Performans ve runtime davranışı
Benchmark sonuçları kütüphane karşılaştırmalarında tartışmalıdır; her ekip kendi senaryosuna göre farklı sayılar gösterir. Yine de tekrarlanabilir nitelikteki ölçümlerden çıkan örüntü şudur: Drizzle ve Kysely, query başına yaklaşık 0,1–0,3 ms tutarında bir orchestrate ek yükü bindirir; Prisma’nın eski Rust engine’i, sürece göre 1–3 ms ek yük getirebilir; yeni Driver Adapters mimarisinde bu sayı belirgin azalır.
| Senaryo (yaklaşık değerler) | Drizzle | Prisma (engine) | Prisma (driver adapter) | Kysely |
|---|---|---|---|---|
| SELECT by PK (p50, ms) | ~1,2 | ~3,0 | ~1,5 | ~1,2 |
| SELECT by PK (p99, ms) | ~3,5 | ~7,0 | ~4,0 | ~3,3 |
| INSERT + RETURNING (p50, ms) | ~1,8 | ~3,4 | ~2,0 | ~1,7 |
| 5-tablo JOIN raporu (p50, ms) | ~6,5 | ~8,2 | ~6,8 | ~6,3 |
| Cold start (Workers/Lambda, ms) | ~50–80 | ~250–400 | ~120–180 | ~40–70 |
| Throughput (RPS, p50 1ms hedef) | ~9.500 | ~3.800 | ~7.200 | ~9.700 |
Yaklaşık değerler, lokal Postgres 16 ve 4 vCPU/8GB bir VM üzerinde yapılan test örüntüsünü temsil eder; gerçek üretim sayıları için Drizzle Benchmarks reposu ve Prisma performance dokümantasyonu incelenmelidir. Önemli not: cold start farkı serverless’ta hâlâ ciddi; Cloudflare Workers gibi 128 MB sınırlı ortamlarda Drizzle veya Kysely çoğu zaman daha öngörülebilir.
Bun 1.2 üzerindeki davranış da kritik. Bun, native bun:sqlite ve PostgreSQL desteğini olgunlaştırdı; Drizzle ve Kysely buna doğal entegre olur, Prisma’nın Bun desteği 2025 itibarıyla “stable beta” sınırında kalıyor. Bun Deno Node.js 22 karşılaştırması yazımızda bu runtime’ların DB driver davranışına etkisi ayrıntılı işleniyor.
Migration disiplini ve şema evrimi
Bir ekip için “araç seçimi” çoğu zaman migration deneyimine bakar. İyi migration süreci üç şeyi sağlar: (1) deterministik, gözden geçirilebilir SQL üretimi; (2) prod’da geri alınabilir adımlar; (3) review hattına oturtulabilir formatta diff. Üç aracın bu boyuttaki karşılaştırması aşağıdadır.
| Migration boyutu | drizzle-kit | prisma migrate | kysely-migration |
|---|---|---|---|
| Diff motoru | SQL üretir (declarative) | SQL üretir (declarative) | Manuel yazılır |
| Dev/Prod ayrımı | push (dev) + migrate (prod) | db push + migrate deploy | Tek mekanizma |
| Shadow DB ihtiyacı | Hayır | Evet (varsayılan) | Hayır |
| Rollback | Manuel SQL | migrate resolve + manuel | down() fonksiyonu |
| Çoklu şema (multi-schema) | Destekli | Sınırlı | Manuel destekli |
| CI dostu | Yüksek | Orta | Yüksek |
| Custom SQL araya sokmak | Doğal | Migration düzenleme gerekir | Doğal |
Prisma’nın migration motoru güçlü ama “shadow database” ihtiyacı, kapalı kurumsal ortamlarda (özellikle networking sınırlı VPC’lerde) sürtünme yaratır. Drizzle, introspect ve generate komutları ile SQL dosyalarını üretip kullanıcıya gözden geçirme şansı bırakır; bu, code review hattıyla iyi geçinir. Kysely tarafında diff motoru yok; bu, “her şeyi sen yaz” felsefesinin doğal sonucu. Küçük ekipte yavaşlatır, büyük ekipte ise “hiçbir migration sürprizi olmasın” isteyenler için ideal.
Migration disiplinini güçlendirmek için klasik test piramidini DB tarafına da uygulamak gerekir: her migration sonrası en az bir kontrat testi (mevcut endpoint hâlâ aynı response veriyor mu) çalıştırılmalı; pre-prod ortamda en az bir geri alma provası yapılmalı.
Edge ve serverless: cold start gerçeği
Cloudflare Workers, Vercel Edge ve Deno Deploy gibi edge runtime’lar 128–256 MB RAM bütçesi ve sınırlı CPU süresi sunar. Bu ortamlarda native binary kabul edilmez, V8 izolasyonu varsayılır. Üç aracın davranışı:
- Drizzle: Pure JS olduğu için
workerdüzerinde sorunsuz çalışır. Neon’un HTTP driver’ı veya Cloudflare Hyperdrive ile birleştiğinde edge’de Postgres üzerinde 30–60 ms p50 mümkün. Ne zaman seç: Workers / Pages Functions üzerinde tam-stack TypeScript yazıyorsanız. - Prisma: Rust engine edge’de çalışmıyordu; Driver Adapters yaklaşımıyla bu sınır aşıldı. Neon, PlanetScale, Turso adapterleri olgun. Ek Accelerate servisi connection pooling ve cache ekliyor (ücretli plan). Ne zaman seç: Ekibiniz Prisma Studio, prisma-erd ve generated client ergonomisine bağlıysa.
- Kysely: Pure JS, edge’de neredeyse sıfır sürtünme.
kysely-planetscale,kysely-d1,@neondatabase/serverlesskombinasyonlarıyla minimal yapı kurulur. Ne zaman seç: Tam SQL kontrolü ve minimum runtime maliyeti istiyorsanız.
Cloudflare’in resmi yönergeleri için Cloudflare Workers Databases dokümantasyonu incelenmelidir; özellikle Hyperdrive ile gelen connection pooling, üç aracın da edge davranışını ciddi iyileştiriyor. Edge tarafında “bağlantı havuzu” sorunu klasik Postgres deployment’larındakinden farklı; her isteğin yeni izolat olduğu modelde driver seviyesinde pooling yetmez.
Dil seçiminin DB katmanı seçimini etkilediğini Go ve Python backend tartışmalarından biliyoruz; TypeScript özelinde de aynı prensipler farklı runtime profilleriyle yeniden geçerli. Edge runtime’da kütüphane seçimi, dil seçiminden bağımsız değil; ikisi birlikte düşünülmeli.
Geliştirici deneyimi ve ekosistem
Bir aracın 5 yıl yaşaması, yalnızca performansla değil, ekosistem genişliğiyle ölçülür. Aşağıdaki tablo, 2025 sonu itibarıyla üç aracın ekosistem manzarasını özetliyor.
| Ekosistem ölçüsü | Drizzle | Prisma | Kysely |
|---|---|---|---|
| GitHub stars (yaklaşık) | ~24.000 | ~39.000 | ~11.000 |
| npm haftalık indirme (yaklaşık) | ~750.000+ | ~2.500.000+ | ~600.000+ |
| Resmi adaptör sayısı | 10+ DB | 8 DB + adapters | 3 ana DB |
| Studio/GUI | Drizzle Studio | Prisma Studio | 3. parti |
| İlişki API’si | Relations API | include/select | Manuel join |
| Auth/Framework entegrasyonu | Lucia, next-auth uyumlu | Geniş kapsam | Lucia uyumlu |
| Dokümantasyon dili | İngilizce | Çok dilli | İngilizce |
| Türkçe topluluk içerik | Orta | Yüksek | Düşük |
Prisma, geniş kapsamla en olgun ekosistem; Drizzle, son 18 ayda en hızlı büyüyen taraf; Kysely ise saf builder ihtiyacı olanlar için referans. Resmi GitHub depolarına şuradan ulaşılabilir: drizzle-orm, prisma, kysely. Ayrıca Stack Overflow Developer Survey 2024 verileri, TypeScript ve PostgreSQL kullanımının sürdürülebilir artışını net göstermektedir.
Toplam maliyet: lisans, hosting ve insan
Üç aracın da çekirdek kütüphaneleri ücretsiz. Maliyet farkı, çevresel servislerden ve operasyonel olgunluktan gelir. Prisma, Accelerate (connection pooling + cache) ve Pulse (CDC stream) gibi managed servisler sunar; başlangıç planı genellikle aylık 25 USD seviyesinden başlayıp veri trafiğine göre artar (resmi fiyatları için Prisma Pricing sayfası incelenmelidir). Drizzle tarafında Drizzle Studio ve drizzle-kit ücretsiz; Hub veya managed servis dayatması yok. Kysely tamamen self-host: ek servis maliyeti yok ama “her şeyi kendin kur” süresi var.
| Maliyet kalemi | Drizzle | Prisma | Kysely |
|---|---|---|---|
| Kütüphane lisansı | Ücretsiz | Ücretsiz | Ücretsiz |
| Managed servis (opsiyonel) | Yok (3rd party) | Accelerate / Pulse | Yok |
| Başlangıç managed plan (yaklaşık) | — | ~25 USD/ay | — |
| Onboarding süresi (mid-level) | ~3–5 gün | ~2–3 gün | ~5–7 gün |
| Bundle/cold-start vergisi | Düşük | Orta (engine’siz) | Çok düşük |
| “Lock-in” riski | Düşük (SQL’e yakın) | Orta (DSL ve client) | Çok düşük |
| Migration güvenliği insan-saati | Az | Az | Orta-fazla |
Bir aracın maliyetini sadece “lisans bedava mı” üzerinden okumak yanıltıcıdır. Drizzle ve Kysely, kütüphane düzeyinde ücretsiz olsa da migration disiplini, monitoring ve connection pooling sorumluluğunu ekibinize bırakır; Prisma, bunları managed servisle satın alma seçeneği sunar. Türkiye’deki ekip yapıları için Yazılım Outsourcing Türkiye 2026 yazımız, geliştirici saati maliyetinin bu seçimde nasıl konumlandığını ayrıntılı işliyor.
Karar matrisi: hangi proje için hangisi?
Üç araçtan birini körü körüne savunmak, mimari hatadır. Aşağıdaki karar çerçevesi gerçek projelerde işe yaramaktadır:
- MVP, hızlı çıkış, geniş ekip: Prisma. Olgun belgeler, generated client, Studio. Ne zaman seç: 2–6 hafta içinde ürün çıkarmak istiyorsunuz, ekipte ORM bilgisi karışık. İlgili rehber: MVP Geliştirme.
- Edge-first, serverless, bundle hassas: Drizzle. Cold start avantajı net, Workers ve Vercel Edge tarafında üretim kanıtlı. Ne zaman seç: Cloudflare Workers, Vercel Edge Functions, AWS Lambda@Edge gibi ortamlar birinci hedef.
- Karmaşık SQL, raporlama, analytics: Kysely. Window function, CTE, advanced join sorgularını manuel yazmak ergonomik. Ne zaman seç: Ekipte güçlü SQL deneyimi var ve “her sorgu tip güvenli olmalı” katı kuralı geçerli.
- Monorepo, yüksek refactor sıklığı: Drizzle veya Prisma — generate adımı CI’da pin’lenmeli. Ne zaman seç: Nx veya Turborepo üzerinde 3+ paket aynı şemayı paylaşıyor.
- Çok-tenant, çok-şema, dynamic schema: Kysely en esnek; Drizzle yetenekli; Prisma sınırlı.
Karar çerçevesi üç sorudan oluşur: (1) Runtime nedir (Node, Bun, Workers)? (2) Şema değişim sıklığı nedir (haftada bir mi, ayda bir mi)? (3) Ekip büyüklüğü ve SQL maturity’si nedir? Bu üç eksenden birinde aşırı uçtaysanız, varsayılan “Prisma” tavsiyesi düşer; ortaysanız Prisma genelde güvenli çıkar. Bu tür mimari kararlar, sadece kütüphane karşılaştırması değil, kod kalitesi disiplinine de bağlı. “Doğru kütüphane yanlış kullanırsa neden işe yaramaz” sorusunun cevabı, SOLID ve test edilebilirlik gibi prensiplerin DB katmanına nasıl uygulandığında yatıyor.
Yaygın anti-pattern’ler ve tuzaklar
Üç aracın da kullanım pratiğinden gelen tekrar eden hatalar var. Bunlar genelde araca değil, ekibin disiplinine bağlı:
- N+1 sorgu pattern’i: Prisma
includeile yardımcı olur, Drizzle Relations API gerektirir, Kysely el ile yazılır. “ORM her şeyi halleder” sanrısı en pahalı maliyettir. - Migration’ı sadece dev’de çalıştırmak: Prod’da
migrate deployveya muadili eksik kalırsa şema sürüklenmesi başlar. CI hattı zorunlu olmalı. - Generated client’ı git’e koymak: Prisma’da klasik hata.
node_modules/.prismagenerate aşaması her CI’da yeniden üretilmeli. - Edge’de uzun bağlantı sanmak: Workers her istekte yeni izolat alır; persistent connection varsayımı veri bozulmasına yol açabilir. Hyperdrive, PgBouncer veya benzeri katmanlar zorunlu.
- Tip güvenliğine aşırı güvenmek: Üç araç da SQL semantiğini değil, yapısal tipleri doğrular.
WHEREşartındaki mantık hatası yine sizin sorumluluğunuzdur. Repository ve unit-of-work pattern’leri bu boşluğu kapatır; sorgu mantığını domain’den ayırmak yine sizin işiniz. - Migration’ı code review’a sokmamak: Üretilen SQL’i okunmamış kabul etmek, en sık veri kaybı nedenidir. Drizzle ve Kysely’de bu doğal; Prisma’da migration dosyalarını review’a açmak şart.
- Sürüm değişiminde regression testi yazmamak: Drizzle 0.30+, Prisma 5+ ve Kysely 0.27+ sürümleri arasında breaking change vardır. Yazılım refactoring legacy modernleştirme yazımızda anlatılan “characterization test” yaklaşımı bu sürüm geçişlerinde önemlidir.
Bu listede gizli mesaj şudur: aracı seçmek karar yolculuğunun yarısıdır, doğru pratiklerle kullanmak diğer yarısıdır. Üç araç da kötü disiplinle ekibi yavaşlatabilir; iyi disiplinle hepsi üretime hazır. Bu noktada bağımsız bir görüş için Ömer Önal’ın TypeScript veritabanı katmanı seçim danışmanlığı, ekibinizin runtime profili ve şema evrim hızına göre yapılandırma önerisi sunar.
Sık Sorulan Sorular (SSS)
Drizzle, Prisma’ya göre gerçekten daha hızlı mı?
Tek bir sorgu p50’sinde fark genelde 1–2 ms seviyesindedir; yüksek RPS ve cold start senaryolarında Drizzle belirgin biçimde öne çıkar çünkü ek runtime engine yoktur. Yine de “Drizzle her zaman hızlı” demek yanlıştır; Prisma’nın Driver Adapters mimarisi farkı önemli ölçüde kapatmıştır. Performans seçimi, sorgu örüntüsüne ve runtime hedefine bağlıdır.
Kysely tek başına bir migration aracı sunuyor mu?
Kysely çekirdeği yalnızca Migrator API’si ve up() / down() fonksiyonları sunar; declarative diff motoru yoktur. Migration dosyalarını siz yazarsınız. 3. parti araçlarla (kysely-migration-cli, kysely-codegen) bu süreç hafifler ama Prisma veya Drizzle ile gelen “şemadan SQL üret” kolaylığı yoktur. Tam kontrol istenen ekipler için avantaj, küçük ekipler için yüktür.
Prisma’yı Cloudflare Workers üzerinde kullanmak mantıklı mı?
2026 itibarıyla Driver Adapters ile mantıklıdır. Neon, PlanetScale ve Turso için resmi adapterler vardır. Yine de cold start, Drizzle veya Kysely’den daha yüksek kalır. Workers’ta Prisma seçimi, ekibin Prisma Studio ve generated client ergonomisine bağlı olduğu durumlarda anlamlıdır; yalın hız için Drizzle veya Kysely tercih edilir.
Drizzle mi Kysely mi: ikisi de pure JS ise hangisi seçilmeli?
Drizzle hafif bir ORM kimliği taşır: ilişkiler, şema diff’i, Studio sunar. Kysely saf query builder’dır. Ekipte ORM kavramına aşinalık ve hızlı CRUD ihtiyacı varsa Drizzle; karmaşık raporlar, dinamik şema ve “her sorguyu ben yazarım” disiplini varsa Kysely. Çoğu ekip için Drizzle daha az sürtünmeyle başlangıç sunar.
Mevcut Prisma projesini Drizzle’a göç ettirmek mantıklı mı?
Sadece performans gerekçesiyle göç önerilmez; ortalama 4–8 haftalık bir yeniden yazma maliyeti vardır. Göç mantıklı olduğu senaryolar: edge-first mimariye geçiş, bundle/cold start kısıtı, generated client ergonomi tartışmaları. Aksi halde Prisma’nın Driver Adapters yapısına geçmek, çoğu zaman aynı kazanımı 1–2 günde sağlar. Karar öncesi prototip kıyaslama yapılmalıdır.
Sonuç
2026’da “drizzle vs prisma vs kysely” sorusunun cevabı tek isim değil, üç eksenli bir karar matrisidir: runtime profili (Node, Bun, Workers), şema evrim hızı ve ekibin SQL olgunluğu. Prisma, geniş ekipler ve generated client ergonomisini önceliklendirenler için en güvenli varsayılan; Drizzle, edge-first ve serverless mimari hedefleyen ekipler için 2025–2026 dönemindeki en güçlü modern seçenek; Kysely ise raporlama ağırlıklı, karmaşık SQL üreten ve “her sorgu denetlenmeli” disiplinine sahip ekipler için ideal araçtır. Üçü de Apache 2.0 / MIT lisansla geliyor, üçü de aktif sürümleniyor, üçü de üretim hazır.
Karar verirken kütüphanenin GitHub yıldız sayısı değil, sizin runtime ve şema profiliniz baskın olmalıdır. Prisma’nın 39k yıldızı, edge’de Drizzle veya Kysely kadar düşük cold-start vermeyecektir; Kysely’nin yalın yapısı, küçük bir CRUD ekibinde lüzumsuz boilerplate yaratacaktır. “Daha iyi” diye bir kütüphane yoktur; “sizin için daha uygun” vardır.
Hangi aracın sizin proje profilinize uyduğundan emin değilseniz, runtime sınırlarınız ve şema değişim hızınız üzerinden bağımsız bir değerlendirme almak süreyi kısaltır. İletişim sayfası üzerinden TypeScript veritabanı katmanı seçimi ve mevcut Prisma / Drizzle / Kysely projelerinizin denetimi için iletişime geçebilirsiniz.
Ömer ÖNAL
Mayıs 16, 2026Yazılım geliştirme projelerinde sıkça gözlemlediğim: kod kalitesi metrikleri (cyclomatic complexity, test coverage) baseline’ı belirlenmeden refactoring kararı veriliyor. Bu yaklaşım %40’ı aşan rework oranıyla sonuçlanıyor. Static analysis araçlarını CI pipeline’a entegre etmek ilk adım. Yorumlarınız?