ORM göçleri. Hepimiz bunlara dört elle sarıldık, değil mi? Prisma, Drizzle — kodunuzu veritabanına sorunsuz taşıyacaklarını vaat ediyorlar, SQL baş ağrısı yok. Ama geçen hafta bir geliştirici yavaş bir API uç noktasında dört saat harcadı, suçlu belli oldu: indeksiz bir foreign key. Şok üstüne şok.
Herkes sihir bekliyordu. TypeScript ilişkilerinizi tanımlayın, göç ettirin, bitti. Users’tan Orders’a bağlantı? Halledildi. Performans? Onların meselesi değil. Ama şimdi tablolar milyonlarca satıra ulaşınca sorgular salyangoz gibi yavaşlıyor, herkesin başına bela oluyor.
Şu var ki, bu yeni bir şey değil. 2005’te Hibernate’ciler aynı tuzağa düşmüştü. ORM’ler acıyı soyutluyor evet, ama görünmez darboğazlar pahasına. Tarih tekerrür ediyor: Araç üreticileri geliştirici hızını veritabanı gerçekliğinin önüne koyuyor. Kim kazanıyor? ORM şirketleri, parlak dokümanları ve kurumsal satışlarıyla — sizin bulut faturanız gökyüzüne fırlarken.
Geçen hafta yavaş bir API uç noktasını debuglemek için 4 saat harcadım. Suçlu mu? ORM’nin “yardımcı” olarak şema göçü sırasında soyutladığı foreign key üzerindeki eksik indeks.
Tam isabet. ORM’ler foreign key kısıtlamasını ekliyor —ALTER TABLE “orders” ADD CONSTRAINT “fk_user” FOREIGN KEY (“user_id”) REFERENCES “users”(“id”);— ama CREATE INDEX “idx_orders_user_id” ON “orders”(“user_id”); kısmını atlıyor. Neden? İndeksleme ‘uygulama detayı’ diyorlar. Saçmalık. Olmadan Postgres her kullanıcı sorgusu için tüm Orders tablosunu sırayla tarıyor. 1K satırda sorun yok. 10M’de felaket.
Geliştiriciler schema.ts’ye bakıyor, gerçek veritabanına değil. İlişkiler? Kodun derinliklerinde gömülü. Görsel harita yok. Uyarı yok. Kara kutu tamamlandı.
Neden ORM Göçleri Her Defa İndeksleri Atlıyor?
Tembel varsayılanlar yüzünden. Prisma’nın göç motoru sonradan optimize edeceğinizi varsayıyor — ya da fark etmeyeceksiniz. Drizzle? Aynı hikaye. Veri bütünlüğü için kısıtlama üretiyorlar, indeksler size kalmış. Otoyol yapıp omuz bırakmamak gibi: Trafik gelene kadar idare eder.
PR lafları mı? ‘Deklaratif şema yönetimi!’ Şirin. Ama ilişkisel gerçeği gizliyor. Uygulamanızın omurgası —tablolar, join’ler, taramalar— JS dosyalarına gömülüyor. Takımların prod’a gönderdiğini, hızlı deploy’ları kutladığını, sonra gecikmenin 100 katına çıktığını gördüm. Kim şaşırıyor?
Benim farklı bakışım: Bu 2012 NoSQL balonu patlamasını andırıyor. Herkes ilişkileri ‘önce ölçekle’ diye terk etti, ACID’i kaybetti, pişman oldu. ORM’ler ilişkisel versiyonu — ölçek sonraya, dua et daha çok.
İşte burada Tiger SQL devreye giriyor. Açık kaynak, tarayıcı tabanlı Postgres görselleştiricisi. Şemayı yapıştırın veya veritabanına bağlanın, hop: İlişkili ERD hazır. AI eksik indeksleri, yavaş sorguları işaretliyor. Şişirme yok, ödeme duvarı yok. GitHub’da fork’layın.
Değiştiriyor mu? Biraz. ORM tembelliğine yama. Ama şema denetimini acısız kılıyor. Yerel çalıştırın, prod patlamadan boşlukları yakalayın.
Tiger SQL Takımınızı ORM Cehenneminden Kurtarır mı?
Belki. Ücretsiz, hafif — tarayıcıda koşuyor. Görsel ERD’ler? Anında. AI optimizasyonu? Eksik B-Tree indekslerini, kullanılmayan sütunları, hatta sorgu planlarını uyarıyor. Tedarikçi kilidi sıfır.
Ama gerçekçi olalım. Böyle araçlar her yıl çıkıyor. DbSchema, pgAdmin eklentileri — aynı vaatler. Tiger’ın farkı? OpenAI faturası olmadan AI zekası, artı açık kaynak saflığı. Kimse burada para kazanmıyor; geliştiricinin kaşıntısını kaşıyor.
Kendim test ettim. Prisma şemasını yükledim: ERD’de user_id’siz indeks parladı. Saniyeler içinde düzeltme önerdi. İşte kazanç — ORM’lerin çaldığı görünürlük.
Şüpheci misiniz? Fork’layın, çalıştırın, kanıtlayın. Ya da inanç temelli göçlere sadık kalın, performans faturasını ödeyin.
Süslü Araçsız Eksik İndeks Avı Nasıl Yapılır
Beklemeyin. Sorgularınızı EXPLAIN ANALYZE ile inceleyin. Foreign key’lerde Seq Scan? Kırmızı bayrak. Sonra:
SELECT schemaname, tablename, indexname, idx_scan
FROM pg_stat_user_indexes
WHERE idx_scan < 100; -- Rarely used indexes
Ya da d
