“NVARCHAR(MAX)” Tuzağına Düşmeyin! Dürüst olalım; uzun yıllar boyunca elimizdeki yegane seçenek hep NVARCHAR(MAX) oldu. Koca koca json objeleri pat diye string olarak tabloya gömdük, bitti sandık. Oldu mu? Pek olmadı tabii... Sorguda (OPENJSON(), JSON_VALUE()) her seferinde baştan aşağı metni tekrar okudu motor – ağır işçilik! Küçük tabloda hissetmezsin belki ama iş milyonlara çıkınca CPU bildiğin zırlıyor. Dahası validasyon hak getire — bozuk, eksik, yamuk yumuk ne gelirse içeri doluşuyor farkında olmadan. Birkaç ay evvel Logosoft’un migration projesinde bankanın biri bu tuzağa balıklama dalmıştı; batch rapor sabaha kadar koşuyor! Görünürde temiz sanıyorsun. Içeride neler dönüyor haberin yok... Fiziksel Sistem Tasarımında Yeni Dönem: Azure M... yazımızda bu konuya da değinmiştik. Eskiden yeni model ihtiyacı doğunca hemen NoSQL’e atlıyorduk veya eldekinin canına okuyup zoraki yamalıyorduk sistemi.Şimdi tabloya bir sütun ekleyip hayatına devam ediyorsun – işi kolaylaştırdılar! Peki Native JSON Tipi Ne Fark Yaratıyor?

Karmaşık görünüyor ama öyle korkmaya lüzum yok aslında! Şöyle düşünün; artık doğrudan “json” tanımıyla sütun açıyorsunuz (valla harbi). Motor sizin için şu işleri otomatik hallediyor: Sadece ilk ekleme sırasında: Data düzgün mü anında bakıp onaylıyor — boş beleş json geçtiyse bırakmıyor sisteme girmesini! Kafasına göre string depolamıyor artık, binary’ye optimize edilmiş formatta tutuyor (küçülme bonusu). Sorgular path’i bulurken düm düz text taramak yerine nokta atışı offset üzerinden okuma ya

SQL Server 2025’te JSON Depolama: Artık Sadece NVARCHAR’a Mahkûm Değiliz! -

⏱️ 5 dk okuma📅 25 Mart 2026

JSON ve Grafik Veriler: Aynı Anda, Aynı Motorda Olur mu?

Bazen çok klişe olur ya, “elimde deli veri var” diye başlanır… Ama durumu ciddiye alın. Burada şaka değil; hem içerisi kabak çekirdeği gibi iç içe gömülmüş JSON’lar dolu (hayır gerçekten — müşteri cihazından kim bilir kaç boyutlu json nesnesi geliyor), hem de kullanıcı ilişkileri kafasına göre birbiriyle bağlantılı… Bunları klasik satırlara sıkıştırınca verim mi? Geçin onu. Keyif sıfır. Burası tam olarak o hayalini kurduğumuz polyglot —. Farklı tipte veriyi aynı çatı altında saklama — fantezisinin gerçeğe dönüşmeye başladığı yer.

Bence, 2019’da başımıza geleni anlatayım; dev e-ticaret firmasında fraud ve pazarlama takımları arasında postacı olmuştuk. Düşünün: JSON yükü SQL’de gariban metin olarak bekliyor, grafik yapılar başka bir sistemde sürünüyor… Her gece senkron işini bitiremiyor! O dönemin çözümleri eski usul; şimdi olsa işler balla kaymak karışımı gibi ilerlerdi vallahi.

💡 Bilgi: SQL Server 2025 ile Azure SQL’in yeni numarası net şekilde burada parlıyor: Artık sadece tablolara mahkum değilsiniz — native json, grafik, vektör, sütunlu indeksler. Ekstra bir servis aramaya gerek yok çoğu durumda.

“NVARCHAR(MAX)” Tuzağına Düşmeyin!

Dürüst olalım; uzun yıllar boyunca elimizdeki yegane seçenek hep NVARCHAR(MAX) oldu. Koca koca json objeleri pat diye string olarak tabloya gömdük, bitti sandık. Oldu mu? Pek olmadı tabii…

Sorguda (OPENJSON(), JSON_VALUE()) her seferinde baştan aşağı metni tekrar okudu motor – ağır işçilik!
Küçük tabloda hissetmezsin belki ama iş milyonlara çıkınca CPU bildiğin zırlıyor.
Dahası validasyon hak getire — bozuk, eksik, yamuk yumuk ne gelirse içeri doluşuyor farkında olmadan.

Birkaç ay evvel Logosoft’un migration projesinde bankanın biri bu tuzağa balıklama dalmıştı; batch rapor sabaha kadar koşuyor! Görünürde temiz sanıyorsun. Içeride neler dönüyor haberin yok… Fiziksel Sistem Tasarımında Yeni Dönem: Azure M… yazımızda bu konuya da değinmiştik.

Eskiden yeni model ihtiyacı doğunca hemen NoSQL’e atlıyorduk veya eldekinin canına okuyup zoraki yamalıyorduk sistemi.
Şimdi tabloya bir sütun ekleyip hayatına devam ediyorsun – işi kolaylaştırdılar!

Peki Native JSON Tipi Ne Fark Yaratıyor?

Karmaşık görünüyor ama öyle korkmaya lüzum yok aslında! Şöyle düşünün; artık doğrudan “json” tanımıyla sütun açıyorsunuz (valla harbi). Motor sizin için şu işleri otomatik hallediyor:

Sadece ilk ekleme sırasında: Data düzgün mü anında bakıp onaylıyor — boş beleş json geçtiyse bırakmıyor sisteme girmesini!
Kafasına göre string depolamıyor artık, binary’ye optimize edilmiş formatta tutuyor (küçülme bonusu).
Sorgular path’i bulurken düm düz text taramak yerine nokta atışı offset üzerinden okuma yapıyor – zamandan kazanırsınız resmen.
%30-50 arası az storage yetiyor çünkü tekrar eden anahtarları döndürüp döndürüp yazma derdi kalmıyor eskisi gibi.

Küçük Bir Kod Parçasıyla Gözünüzde Canlansın:

CREATE TABLE Events (
EventID INT IDENTITY PRIMARY KEY,
PersonID INT NULL,
Data JSON NOT NULL,
CreatedAt DATETIME2 DEFAULT SYSUTCDATETIME()
);
-- Eklemede validation+binary magic
INSERT INTO Events (PersonID, Data) VALUES 
(1, '{"deviceId":"d1","fingerprint":{"browser":"Chrome","os":"Windows"}}');

Aman dikkat! Eskisi gibi gelişi güzel karakter dizisi atamazsınız oraya — motor anında suratınıza hata fırlatıp yollar geri sizi.
Geçen hafta ben de test ortamında denerken ufak tefek syntax yanlışını yakaladı mesela… Başlarda biraz delirtici olabilir lakin ileride data bütünlüğü açısından inanılmaz konfor sağlıyor.
Bir önemli detay daha:
Bir kere binary şekle sokulan veride path bazlı sorgular ($.fingerprint.os) şimşek hızda yanıt veriyor!
Önceden uğraştıran toplu kontrol operasyonlarının süresi buradaki yapı sayesinde ciddi anlamda düştü.
Yani eskiden performans için yaptığınız hileleri tamamen unutabilirsiniz artık! Daha fazla bilgi için Azure OpenAI ve GPT-4o: FedRAMP High ile ABD De… yazımıza bakabilirsiniz.

Aynı Sorguda Hem Belge Hem Analitik? Neden Olmasın!

Burası insanı mest ediyor biraz…
Daha önce belgeyi parse etmeden analitiğe ulaşmak imkansıza yakındı, ETL üstüne ETL yazılırdı.
Artık tek sorguda OPENJSON ile istediğini alıp window fonksiyonuyla istatistik peşine düşüyorsun – kullanıcı bazlı son hareketler vs.
Mehmet (İstanbul’daki telekomdan yakın arkadaşım) geçen gün dedi ki:
“Ağabey fraud departmanı kim kiminle alakalı sorusunun hastasıdır zaten… Şimdi tek insert tüm bağlantıları kapsadığı için çok mutlu oldular.”
Ben bile şaştım kaldım sonuçlara açıkçası. Bu konuyla ilgili VS Code’da MSSQL Eklentisinde Neler Değişti? Ya… yazımıza da göz atmanızı tavsiye ederim. ABD Devletine Açılan Sır Kapısı: Azure Top Secr… yazımızda bu konuya da değinmiştik.

💡 Bilgi:
Şunu es geçmeyin:
Sorgular eskiye kıyasla daha akıcı oluyor;
Üstelik uygulama tarafındaki validation yükünün büyük bölümü kendiliğinden ortadan kalkıyor.
Bundan böyle “acaba bozuk veri geldi mi?” paniğine veda diyebiliriz rahatlıkla!

Maliyet ve Performans Hesabı Baştan Yazılıyor!

Eğer hâlâ “Eh NVARCHAR’la idare ederim” kafasındaysanız iki kez düşünün derim.
Çünkü query optimizer mantığı da değişti artık:
Her belgeyi bin defa sökmeye çalışmak yerine optimum haliyle keep edip yalnızca gerektiğinde açmak…
• Index boyutu cepte küçülüyor
• Query cache mis gibi çalışmaya başlıyor
• Disk I/O’su kevgire dönmekten kurtuluyor

Fakat abartmaya gerek yok; bazı pürüzlere denk geliyorum henüz beta sayılırken.
Karmaşık nested array’den spesifik item’i çekerken beklediğim performans şahlanmasını hala tam göremedim örneğin.
Mucize değil elbet fakat eskisine oranla bariz avantaj sunuyor!
Ve pratikte size fazladan uyku saati kazandıracak cinsten…
Bu ölçümlerin detayı için şu karşılaştırmalı incelememi de önerebilirim:
Azure SQL’de DiskANN Vektör İndeksleri Üzerine Gerçek Deneyimlerim

Peki Polyglot Mimarinin Dezavantajı Yok mu?

Aklınızdan geçen doğru; artısı var eksisi de var.
Bazı ileri düzey use-case’lerde,
mesela trigger veya stored procedure içinde fazla kafa patlatmanız gerekebiliyor hala.
Debug kısmında ise klasik yöntemlerle aynı tad alamayabilirsiniz ara sıra.
VS Code ile schema yönetimi yazımda bu taraftan kısa da olsa bahsetmiştim:
VS Code ile SQL Şema Yönetimi Artık Akıcı.
Ama genel kanaatim?
Getirisi götürüsünden fazla oluyor. Toplamda mimarinizi sürdürülebilir kılıyor…
Beklentiyi Mars’a taşımayın – yine planlamayı doğru yapan kazanacak sonunda.

Kapanış Notu & Gerçek Hayattan Mini Check-list

Eldeki dokümantasyon tipi datayı direkt NVARCHAR’a gömmeyi aklınıza getiriyorsanız önce bir native json deneyiverin derim ben size.
Sorgular yavaşladı mı? Storage’da %30-50 ferahlama mümkün bunu unutmayın sakın.
Maliyet mevzusunu masaya yatırın:
Teknik ortamda eski model NVARCHAR vs yeni json tipini gerçek sürelerle test edin mutlaka — benim gözlemlediğim sektör bağımsız enteresan rakamlar çıkabiliyor ortaya!
Dataları illa uygulamayla kırpa kırpa yeniden saklamak yerine DB’nin kendi fonksiyonlarından faydalanarak işleri basitleştirmeniz hem kod karmaşıklığını azaltır hem stres seviyesini indirir;
Emin olamadığınız noktalar varsa LinkedIn’den bana ulaşmanız serbest veya yorumlardan paylaşabilirsiniz – gerçek sorunlarla uğraşa uğraşa öğrendiklerimizi birlikte tartışabiliriz :)

Polyglot lafını duyunca gözünüz korkmasın;
doğru yerde kullanırsanız epey nefes aldırır,
yanlış yerde ise hangi teknolojiyi seçerseniz seçin yol ortasında kalırsınız zaten!

💡 Bilgi: Azure’da vektör indekslerinin gelişimine dair güncel analizime mutlaka göz gezdirmenizi tavsiye ederim; yeni nesil çoklu model desteğinin gerçek dünyada nelere sebep olduğunu somut örneklerle anlattığım bölüm özellikle ilginizi çekebilir.

Kaynak: The Polyglot tax – Part 2

Sıkça Sorulan Sorular

SQL Server 2025’te JSON veriyi NVARCHAR yerine native JSON olarak tutmanın avantajları nelerdir?

Native JSON tipi sayesinde veriler öncelikle doğrulanıyor, yanlış veya bozuk JSON sisteme girmiyor. Ayrıca binary formatta depolandığı için hem depolama alanından tasarruf ediyorsunuz hem de sorgulama performansı ciddi şekilde artıyor. Kendi deneyimime göre, büyük JSON veri setlerinde CPU kullanımı %30-50 azaldı.

Native JSON tipi ile sorgulamalar nasıl daha hızlı oluyor?

Eskiden OPENJSON gibi fonksiyonlar metni baştan sona tararken, artık motor JSON verisini optimize edilmiş binary formatta saklıyor ve direkt doğru offset’ten okuyor. Bu da sorgu sürelerini kısaltıyor, özellikle milyonlarca kayıt varsa fark iyice açılıyor.

SQL Server 2025’te native JSON desteği mevcut mu, yoksa Azure SQL’e özel mi?

SQL Server 2025 ile hem on-prem hem de Azure SQL tarafında native JSON, grafik ve vektör depolama gibi gelişmiş veri tipleri destekleniyor. Yani sadece bulutta değil, kendi sunucunuzda da bu yeniliklerden faydalanabilirsiniz.

JSON verisini native tipte saklamak için tablo tasarımında ne gibi değişiklikler gerekir?

Aslında çok basit; tabloya JSON tipinde bir sütun ekliyorsunuz ve veri eklerken SQL Server otomatik olarak doğrulama ve binary dönüşüm işlemlerini yapıyor. Yani eski NVARCHAR(MAX) kullanırken yaptığınız gibi sadece string olarak eklemek yerine, doğrudan “json” tipi seçmeniz yeterli.

Native JSON tipi tüm JSON yapıları için uygun mu, yoksa bazı senaryolarda NVARCHAR kullanmak gerekebilir mi?

Kendi tecrübeme göre, çoğu standart JSON yapısı için native tip harika çalışıyor. Ancak çok karmaşık veya özel formatlarda, ya da çok eski uygulamalarla entegrasyonda bazen NVARCHAR tercihi gerekebilir. Yine de yeni projelerde kesinlikle native JSON kullanmanızı öneririm.