Prisma 6'dan 7'ye Geçiş: Rust Motoru Gitti, Ne Değişti?

Prisma 6 kullanıyorsan ve npm install prisma çalıştırdığında karşına 8.x serisinin gelmesi seni şaşırttıysa yalnız değilsin: npm'deki latest etiketi artık Prisma 8'in release candidate sürümüne (8.0.0-rc.13) işaret ediyor, oysa production için önerilen stabil sürüm hâlâ Prisma 7.10.0. Bu yazıda Prisma 6'dan Prisma 7'ye — Rust motorunun tamamen kaldırıldığı, prisma.config.ts'in devreye girdiği, driver adapter'ların zorunlu hale geldiği sürüme — güvenli bir geçiş rehberi bulacaksın; Prisma 8'in hâlâ RC aşamasında olduğunu ve ne zaman geçmen gerektiğini de netleştireceğiz.

💡 Pro Tip: Geçişe başlamadan önce npm view prisma dist-tags komutunu çalıştır — latest etiketi RC sürüme işaret edebilir, sen production için açıkça [email protected] yazmalısın.

İçindekiler

• Prisma 7 Mimarisi: Rust Engine Yerine WASM
• Neden önemli
• Query Compiler ne yapıyor, driver adapter neden hâlâ gerekli
• Kaldırılan bileşenler
• prisma.config.ts'e Taşınma
• schema.prisma'nın yerini almıyor, rolünü değiştiriyor
• Minimum sürüm gereksinimleri
• Custom Output Path'i Olan Projelerde Tuzaklar
• CI/CD önbelleğine dikkat
• Import yolu bir seviye derinleşiyor
• tsconfig ve bundler path alias'larını da kontrol et
• Driver Adapters GA — Postgres İçin Ne Değişti
• Bağlantı havuzunu adapter seviyesinde düşün
• Migration'ı Güvenli Koşmak (migrate diff, --force'suz)
• Seed script'ini de unutma
• Bundle Boyutu ve Cold Start Ölçümü
• Neden bu rakam serverless'te önemli
• Basit bir ölçüm script'i
• Prisma 8 RC'de Ne Var, Ne Zaman Geçilir
• Dokümana bakarken sürüm karışıklığı
• Kademeli geçiş için compatibility paketi
• Geri Alma Planı
• Staging'de prova yap, production'da sürpriz yaşama
• SSS
• Prisma 6'dan 7'ye geçerken hangi breaking change'ler var?
• prisma.config.ts nedir, schema.prisma'nın yerini mi alıyor?
• Custom client output path Prisma 7'de nasıl tanımlanır?
• Prisma 8 RC'yi production'da kullanmalı mıyım?
• Sonuç
• Kaynaklar

Prisma 7 Mimarisi: Rust Engine Yerine WASM

Prisma'nın sorgu motoru yıllarca Rust ile yazılıp native binary (Query Engine) olarak dağıtılıyordu — LibraryEngine, BinaryEngine, DataProxyEngine, AccelerateEngine ve ReactNativeEngine gibi farklı çalışma ortamları için ayrı derlemeler gerekiyordu. Prisma 7 ile bu mimari tamamen tarih oldu: sorgu motoru artık TypeScript ve WebAssembly ile yazılan bir "Query Compiler"a dönüştü, native binary indirme adımı kalktı. Prisma ekibi bu geçişi kademeli yaptı — resmi Rust'tan-TypeScript'e blog yazısına göre yeni mimari v6.16 ile production-ready hale geldi, ardından Prisma 7.0.0 ile (19 Kasım 2025) varsayılan davranış oldu.

Neden önemli

Native binary'lerin kalkması, serverless/edge ortamlarında (Vercel Edge, Cloudflare Workers gibi) cold start süresini doğrudan etkiliyor — binary indirme veya soğuk başlatmada native modül yükleme adımı artık yok. Resmi 7.0.0 duyuru yazısının ilk iki sonuç maddesi birebir: "90% smaller bundle output" ve "3x faster query execution".

Query Compiler ne yapıyor, driver adapter neden hâlâ gerekli

Eski mimaride Rust binary'si hem sorguyu SQL'e çeviriyor hem de veritabanına bağlanıp SQL'i çalıştırıyordu — tek bir kapalı kutu. Yeni mimaride bu iki iş ayrıldı: TypeScript/WASM tabanlı Query Compiler yalnızca Prisma sorgusunu SQL'e çeviriyor, gerçek bağlantıyı kurup sorguyu çalıştırma işini ise driver adapter (@prisma/adapter-pg gibi) üstleniyor. Bu ayrım, bir sonraki bölümde göreceğin gibi neden artık PrismaClient'a bir adapter geçmen gerektiğini açıklıyor — adapter olmadan compiler'ın ürettiği SQL'i çalıştıracak hiçbir şey yok.

Kaldırılan bileşenler

Bu tablo Prisma'nın resmi 7.0.0 changelog'undaki (19 Kasım 2025) mimari değişiklik notlarına dayanıyor. Pratikte bu, prisma generate sonrası artık ayrı bir native binary dosyası aramana gerek kalmadığı, ama karşılığında her veritabanı için bir driver adapter tanımlaman gerektiği anlamına geliyor — bir sonraki bölümde bunu detaylandıracağız.

prisma.config.ts'e Taşınma

Prisma 7'de schema.prisma dosyası model tanımlarını tutmaya devam ediyor — ortadan kalkmıyor. Değişen şey, CLI'nin migration/introspection için ihtiyaç duyduğu bağlantı bilgisi: resmi yükseltme rehberi datasource bloğundaki url, directUrl ve shadowDatabaseUrl alanlarını deprecated sayıyor, CLI ise bunları schema dosyasında görürse P1012 ile durduruyor. Bağlantı artık prisma.config.ts içinde tanımlanıyor; config'in directUrl diye ayrı bir alanı yok — o değeri url alanına yazarsın, kabul edilen alanlar url ve shadowDatabaseUrl.

1import "dotenv/config";
2import { defineConfig, env } from "prisma/config";
3 
4export default defineConfig({
5  schema: "prisma/schema.prisma",
6  migrations: {
7    path: "prisma/migrations",
8    seed: "tsx prisma/seed.ts",
9  },
10  datasource: {
11    url: env("DATABASE_URL"),
12  },
13});

Eğer bu satırı schema.prisma'da bırakırsan CLI seni P1012 hatasıyla durdurur: "The datasource property 'url' is no longer supported in schema files" — bu tam olarak canlı bir GitHub issue'sunda karşılaşılan hata mesajı.

schema.prisma'nın yerini almıyor, rolünü değiştiriyor

prisma.config.ts bir yapılandırma dosyası — model/tablo tanımların hâlâ schema.prisma içinde kalıyor. Aradaki fark: eskiden CLI, .env dosyasını otomatik okuyup datasource bloğundaki url'yi çözerdi; artık bu bağlantı çözümleme mantığı prisma.config.ts içinde açıkça yazılıyor (yukarıdaki örnekte dotenv/config import'u ve tip güvenli env() yardımcısı bunun için). Bu, migration/seed komutlarının hangi ortam değişkenini nereden okuyacağını daha şeffaf hale getiriyor ama unutulursa prisma migrate komutları bağlantı bulamadığı için hata verir.

Prisma'nın resmi referans sayfası prisma.config.ts içinde schema, migrations.path, migrations.seed ve datasource.url alanlarını tanımlıyor — seed script'ini artık package.json'daki prisma.seed alanı yerine burada belirtiyorsun.

Minimum sürüm gereksinimleri

Bu değerler resmi yükseltme rehberinden alınıyor; Prisma 6'da bu gereksinimler daha esnekti, dolayısıyla eski bir Node LTS sürümü üzerinde çalışan projelerde geçiş öncesi runtime yükseltmesi de gerekebilir. ESM zorunluluğu özellikle CommonJS tabanlı eski seed script'lerinde (require() kullanan) ek bir dönüşüm gerektirebilir.

Custom Output Path'i Olan Projelerde Tuzaklar

src/generated/prisma gibi bir custom output path kullanan projeler için Prisma 7'nin en can yakıcı değişikliği burada. Prisma 6'da generator client bloğunda output alanı opsiyoneldi — belirtmezsen client node_modules/@prisma/client içine üretilirdi. Prisma 7'de bu davranış tersine döndü: output alanı artık zorunlu, ve varsayılan olarak node_modules içine üretim tamamen kaldırıldı.

1generator client {
2  provider = "prisma-client"
3  output   = "../src/generated/prisma"
4}

Dikkat: provider değeri de değişti — eski prisma-client-js yerine yeni Rust-free client için prisma-client yazman gerekiyor. Bu tek satırlık değişiklik atlanırsa generate işlemi eski JS client'ı üretmeye devam eder ve yeni mimarinin performans kazanımlarından hiçbiri gelmez.

CI/CD önbelleğine dikkat

generator client bloğunu değiştirdikten sonra prisma generate komutunu yeniden çalıştırmadan eski client'la devam edersen, yeni provider/output ayarları hiçbir zaman devreye girmez — TypeScript derleyicisi eski dosyaları görmeye devam eder. CI/CD pipeline'larında node_modules veya build önbelleği (.next/cache, .turbo gibi) arasında prisma generate adımını atlayan bir cache-restore adımı varsa, bu durum production'da "değişiklik yaptım ama etkisi yok" şeklinde kafa karıştırıcı bir davranışa yol açabilir. Geçiş sonrası ilk birkaç deploy'da build loglarında prisma generate adımının gerçekten çalıştığını (cache'ten atlanmadığını) doğrulamak, bu tür sessiz hataları erken yakalamanın en pratik yolu.

Import yolu bir seviye derinleşiyor

Custom output kullanan projelerde import satırı da değişiyor — üretilen client artık bir client alt klasörüne yazılıyor:

1// Prisma 6 (eski)
2import { PrismaClient } from "../generated/prisma";
3 
4// Prisma 7 (yeni)
5import { PrismaClient } from "../generated/prisma/client";

Bu tek satır kolayca gözden kaçar çünkü TypeScript derleme hatası genelde net değildir — "Cannot find module" mesajı, output yolunu değiştirdiğini unutan geliştiriciyi yanlış yöne (path alias, tsconfig) yönlendirebilir. Geçiş yaparken projedeki her import'u tek tek kontrol etmek, IDE'nin otomatik tamamlamasına güvenmekten daha güvenli — çünkü eski yol hâlâ diskte var olabilir (stale build) ve derleme sessizce eski client'ı çözebilir.

tsconfig ve bundler path alias'larını da kontrol et

Custom output kullanan projelerde genelde bir tsconfig path alias'ı da tanımlanır (@/generated/prisma gibi). Bu alias paths alanında hâlâ eski klasör derinliğine işaret ediyorsa, IDE üzerinden hata görünmeyebilir çünkü TypeScript sunucusu eski önbelleği kullanmaya devam edebilir — ama gerçek tsc --noEmit veya production build'i eski yolu bulamadığı için patlar. Geçiş sonrası önce IDE'yi yeniden başlatmadan, doğrudan komut satırından tip kontrolü çalıştırmak sahte-yeşil bir geçişi engelliyor.

1npx tsc --noEmit

Next.js gibi bir framework kullanıyorsan, standalone build çıktısının da (varsa) yeni client yolunu kopyaladığından emin olmak gerekiyor — build script'lerinde eski yola sabit referans varsa (örneğin bir cp -r komutu), bu satırın da güncellenmesi gerekir.

Driver Adapters GA — Postgres İçin Ne Değişti

Prisma 7'de yeni Prisma Client oluşturma şekli, tüm veritabanları için bir driver adapter'ı zorunlu kılıyor. PostgreSQL kullanan projeler için bu adapter @prisma/adapter-pg (node-postgres tabanlı):

1import { PrismaClient } from "../generated/prisma/client";
2import { PrismaPg } from "@prisma/adapter-pg";
3 
4const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL });
5const prisma = new PrismaClient({ adapter });

PostgreSQL + Prisma kullanan bir kurulumda pratik etkisi şu: PrismaClient artık parametresiz çağrılamıyor, adapter nesnesi geçmen gerekiyor. Projede birden fazla yerde (API route'lar, cron script'leri, seed dosyası) new PrismaClient() çağrısı varsa, hepsini tek bir merkezi client modülünden re-export etmek geçişte tekrar tekrar adapter kurulumu yazmanı önler.

⚠️ Not: MongoDB kullanan projeler için Prisma 7 henüz desteklenmiyor — resmi geçiş kılavuzu MongoDB kullanıcılarının şimdilik Prisma 6'da kalmasını söylüyor.

Bağlantı havuzunu adapter seviyesinde düşün

Driver adapter'a geçince bağlantı havuzu (connection pool) davranışı da artık doğrudan altındaki sürücünün (node-postgres) sorumluluğuna giriyor — eskiden Rust engine'in kendi içinde yönettiği havuzlama mantığı, şimdi @prisma/adapter-pg'nin sarmaladığı pg.Pool ayarlarına bağlı. Serverless ortamda çok sayıda eşzamanlı fonksiyon çağrısı varsa, adapter'ı oluştururken havuz boyutunu (max gibi) veritabanının bağlantı limitine göre elle ayarlamak, geçiş sonrası "too many connections" hatalarını önlemek için gözden geçirilmesi gereken bir ayar.

Migration'ı Güvenli Koşmak (migrate diff, --force'suz)

Sürüm geçişinden bağımsız olarak, migration'ları production'a uygularken kalıcı geçerli bir disiplin var: şema değişikliğini önce görünür kılmadan uygulamamak. prisma migrate diff komutu, iki şema/veritabanı durumu arasındaki farkı hiçbir şeyi değiştirmeden SQL olarak gösterir — bunu CI'da bir kapı olarak kullanmak, beklenmedik bir DROP COLUMN'u production'a gitmeden yakalamanı sağlar:

1npx prisma migrate diff \
2  --from-config-datasource \
3  --to-schema=prisma/schema.prisma \
4  --script

prisma db push --force-reset veya migrate reset --force gibi bayraklar yalnızca lokal/staging ortamda, verinin kaybolmasını göze aldığın senaryoda kullanılmalı — production'da her zaman prisma migrate deploy ile, önceden migrate diff çıktısını okuyarak ilerlemek, Prisma 7'ye geçerken de değişmeyen tek kural.

Seed script'ini de unutma

prisma.config.ts'e geçtiğinde seed komutunun tanımı da yer değiştiriyor — eskiden package.json içindeki prisma.seed alanında tutulan komut artık migrations.seed alanına taşınıyor. Bu iki tanımı aynı anda bırakmak karışıklığa yol açar; package.json'daki eski prisma alanını tamamen kaldırıp tek kaynak olarak prisma.config.ts'i bırak. Asıl kırıcı değişiklik şu: rehbere göre Prisma 6'da prisma migrate dev/migrate reset seed script'ini migration sonrası otomatik çalıştırıyordu; bu davranış Prisma 7'de kaldırıldı — artık npx prisma db seed komutunu açıkça çalıştırman gerekiyor. Prova sırasında seed'i staging'de elle çalıştırıp beklenen veriyi doğrulamak bu yüzden atlanamaz.

Bundle Boyutu ve Cold Start Ölçümü

Prisma'nın resmi 7.0.0 duyuru yazısı Rust-free mimarinin sonucunu madde madde veriyor: %90 daha küçük bundle çıktısı, 3 kat daha hızlı sorgu çalıştırma, belirgin şekilde daha düşük CPU/bellek kullanımı. Bu rakamlar Prisma'nın kendi ölçümü — kendi projende doğrulamak için en pratik yöntem, geçiş öncesi ve sonrası aynı serverless fonksiyonun soğuk başlatma süresini loglamak.

Neden bu rakam serverless'te önemli

Native binary'nin kalkması, fonksiyon paketinin diskte kapladığı alanı ve bu paketin soğuk başlatmada okunma süresini doğrudan etkiliyor — eski mimaride her cold start'ta platform-özel binary'nin (Linux/musl/ARM gibi) doğru sürümünün bulunması ve yüklenmesi gerekiyordu. WASM tabanlı motor bu adımı ortadan kaldırıyor. Kendi ortamında kesin rakamı almak için tahmine değil gerçek ölçüme güven — resmi rakam bir üst sınır, senin kazanımın kullandığın platforma göre değişir.

Basit bir ölçüm script'i

Kesin rakamı kendi projende almak için karmaşık bir tooling'e gerek yok — client'ı import edip bağlanma süresini ölçen birkaç satır yeterli:

1const start = performance.now();
2import { PrismaPg } from "@prisma/adapter-pg";
3const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL });
4const { PrismaClient } = await import("../generated/prisma/client");
5const prisma = new PrismaClient({ adapter });
6await prisma.$connect();
7console.log(`init: ${(performance.now() - start).toFixed(1)}ms`);

Bu script'i geçiş öncesi eski client ile, geçiş sonrası yeni client ile aynı ortamda (aynı serverless bölgesi, aynı veritabanı) çalıştırıp iki sayıyı karşılaştırmak, resmi rakamlara güvenmek yerine kendi projenin gerçek kazanımını görmenin en pratik yolu.

Prisma 8 RC'de Ne Var, Ne Zaman Geçilir

2026-09-08 itibarıyla npm'deki prisma paketinin dist-tag'lerine bakıldığında tablo şöyle: prev: 7.10.0, latest: 8.0.0-rc.13, next: 8.0.0-rc.10. Yani npm install prisma bugün çalıştırılırsa doğrudan bir release candidate sürümü kurulur — production kurulumlarında bunu istemezsin.

1# Yanlış: latest'i körü körüne kurar (RC olabilir)
2npm install prisma
3 
4# Doğru: production için sürümü açıkça sabitle
5npm install [email protected] @prisma/[email protected]

Prisma'nın dokümantasyon sitesi artık varsayılan olarak Prisma 8 içeriğini gösteriyor, Prisma 7 dokümantasyonu ayrı bir /orm/v7 yolunda tutulmaya devam ediyor — bu da dokümana bakarken hangi sürümdesin diye kontrol etmeyi gerektiriyor. Yani Prisma 8 duyuruldu ama npm'de stabil bir 8.0.0 hâlâ yok. Riskli olmayan bir üretim geçişi istiyorsan 6'dan 7'ye geçişi önce tamamlayıp sürümü 7.10.0'a sabitlemek, 8'e geçişi stabil sürüm yayımlandığında ayrı bir adım olarak planlamak daha güvenli.

Dokümana bakarken sürüm karışıklığı

Prisma'nın resmi dokümantasyon sitesi artık Prisma 8'i varsayılan olarak gösteriyor; Prisma 7'nin dokümanları ayrı bir /orm/v7 yolunda saklanıyor. Bu, geçiş sürecinde bir arama motorundan doküman sayfasına düştüğünde önemli bir tuzak: gördüğün örnek kod Prisma 8'e ait olabilir ama sen hâlâ Prisma 7 üzerinde çalışıyor olabilirsin. Herhangi bir Prisma doküman sayfasına baktığında URL'de /v7 segmentinin olup olmadığını kontrol etmek, yanlışlıkla henüz stabil olmayan bir 8.x API'sini kopyalayıp production koduna yapıştırmanı önler.

Kademeli geçiş için compatibility paketi

7.10.0 ile aynı gün (25 Ağustos 2026) Prisma ekibi npm'e @prisma/prisma7 adında bir paket yayımladı — npm'deki tanımı birebir "Compatibility wrapper for running the Prisma 7 CLI" ve paket prisma7 adında bir komut kuruyor, yani 8.x'e geçtikten sonra da 7 komutlarını ayrı isimle çağırabiliyorsun. Bu, "önce 6'dan 7'ye, sonra 7'den 8'e" şeklinde iki ayrı, kontrollü adımla ilerlemek isteyenler için pratik bir köprü; 8 GA'ya çıktığında ayrı bir yazıda ele alınacak.

Geri Alma Planı

Geçiş sırasında bir şey ters giderse, geri dönüş net ve tersine çevrilebilir adımlardan oluşuyor:

• package.json'da sürümü sabitle: prisma ve @prisma/client paketlerini 7.x'ten önceki son 6.x sürümüne indir (npm install prisma@6 @prisma/client@6).
• generator client bloğunu eski haline getir: provider = "prisma-client-js", output alanını kaldır (veya eski yoluna döndür).
• prisma.config.ts'i kaldır, datasource bloğuna url'yi geri koy: Prisma 6'da bağlantı bilgisi yeniden schema.prisma içinde tanımlanır.
• Driver adapter'ı kaldır: new PrismaClient({ adapter }) çağrısını parametresiz new PrismaClient()'a döndür, @prisma/adapter-pg bağımlılığını kaldır.
• Import yollarını bir seviye sığlaştır: .../generated/prisma/client → .../generated/prisma.

Bu adımların her biri, geçiş sırasında attığın adımın tam tersi olduğu için, geçişi yaparken her değişikliği ayrı bir commit'te tutmak geri almayı çok daha hızlı hale getirir — özellikle production'da bir sorun 5 dakika içinde çözülmesi gerekiyorsa.

Staging'de prova yap, production'da sürpriz yaşama

Geri alma planının en değerli kısmı, onu hiç kullanmak zorunda kalmamak. Geçişin tamamını önce staging ortamında uçtan uca çalıştırıp — generator değişikliği, prisma.config.ts, driver adapter, import yolları — gerçek bir deploy döngüsünden geçirmek, production'da karşılaşabileceğin sürprizlerin çoğunu önceden gösterir. Özellikle CI'da tsc --noEmit ve prisma migrate diff adımlarının her ikisinin de yeşil çıktığını gördükten sonra production'a geçmek, geri alma planını "olası ama gerekmeyecek bir güvenlik ağı" haline getirir.

SSS

Prisma 6'dan 7'ye geçerken hangi breaking change'ler var?

En büyük değişiklik, Rust tabanlı query engine ailesinin (LibraryEngine, BinaryEngine, DataProxyEngine, AccelerateEngine, ReactNativeEngine) tamamen kaldırılıp yerine TypeScript/WASM tabanlı bir Query Compiler'ın gelmesi. Buna bağlı olarak her veritabanı için bir driver adapter zorunlu hale geldi (PostgreSQL için @prisma/adapter-pg), generator bloğundaki provider değeri prisma-client-js'ten prisma-client'a değişti, output alanı zorunlu oldu ve datasource bloğundaki bağlantı bilgileri prisma.config.ts dosyasına taşındı. Ayrıca Prisma 7 ESM olarak dağıtılıyor (type: module şart) ve SSL varsayılanları değişti: geçersiz sertifikalar artık yok sayılmadığından P1010 hatası görebilirsin.

prisma.config.ts nedir, schema.prisma'nın yerini mi alıyor?

Hayır, yerini almıyor. schema.prisma model tanımlarını tutmaya devam ediyor; prisma.config.ts ise CLI'nin migration, introspection ve seed işlemleri için kullandığı bağlantı URL'si ile migration path'ini tutuyor. Prisma 7'de datasource bloğundaki url satırı schema dosyasından kaldırılmak zorunda, aksi halde CLI P1012 hatası veriyor.

Custom client output path Prisma 7'de nasıl tanımlanır?

generator client bloğunda output alanı artık zorunlu: output = "../src/generated/prisma" gibi bir yol belirtiyorsun, provider değerini de prisma-client yapıyorsun. Üretilen client'tan import artık bir seviye daha derinden yapılıyor — .../generated/prisma/client şeklinde, eski .../generated/prisma yolu değil.

Prisma 8 RC'yi production'da kullanmalı mıyım?

Hayır. 2026-09-08 itibarıyla 8.0.0-rc.13 hâlâ release candidate aşamasında; npm'deki latest etiketi bu sürüme işaret etse de production kurulumlarında sürümü açıkça 7.10.0'a sabitlemek gerekiyor. Kademeli geçiş isteyenler için Prisma ekibinin 7.10.0 ile birlikte sunduğu @prisma/prisma7 uyumluluk paketi bir köprü sağlıyor.

Sonuç

Prisma 6'dan 7'ye geçiş, tek seferde her şeyi değiştiren bir refactor değil — sırayla generator bloğunu güncelleyip, prisma.config.ts'i oluşturup, driver adapter'ı ekleyip, import yollarını düzelttiğinde ilerleyen kontrollü bir süreç. Custom output path kullanan projelerde en çok atlanan adım, output alanının zorunlu hale gelmesi ve import yolunun derinleşmesi; bunu bir kontrol listesiyle (yukarıdaki Okuyucu Ödülü) takip etmek geri dönüşü de kolaylaştırıyor. Prisma 8 henüz RC aşamasında olduğu için bu geçişi tamamlamak, önümüzdeki büyük sıçrama için de seni hazırlıyor.

Backend tarafında ORM ve veritabanı seçimlerini derinleştirmek istersen Drizzle ORM ile Turso/SQLite edge pattern'ini incelemeni öneririm. Serverless framework tarafında Hono.js ile production serverless mimarisini, edge fonksiyonları için Supabase Edge Functions ve Deno runtime'ını okuyabilirsin. GraphQL + managed Postgres kombinasyonu ilgini çekerse Firebase Data Connect ile GraphQL/Cloud SQL yazısı, vektör veritabanı tarafında ise Pinecone, Weaviate ve Qdrant karşılaştırması tamamlayıcı olacaktır.

Kaynaklar

• Prisma ORM 7.0.0 Duyurusu — Rust-free mimari, %90 daha küçük bundle ve 3 kat daha hızlı sorgu çalıştırma iddiaları
• Prisma Changelog: 2025-11-19 — Prisma ORM 7.0.0'ın resmi yayın tarihi ve mimari değişiklik notları
• Rust'tan TypeScript'e: Prisma ORM için Yeni Bir Bölüm — WASM tabanlı Query Compiler mimarisinin v6.16'dan itibaren production-ready hale gelişi
• Prisma 7'ye Yükseltme Rehberi — output alanı, import yolu, Node/TypeScript minimum sürüm ve MongoDB istisnası
• prisma.config.ts Referansı — defineConfig yapısı, schema ve migrations alanları
• npm prisma dist-tags — latest etiketinin 8.0.0-rc sürümüne işaret ettiğinin canlı kanıtı
• GitHub Issue #28573 — datasource url hatasının gerçek production örneği
• npm: @prisma/prisma7 — 7.10.0 yayın tarihi ve resmi paket tanımı