PostgreSQL JSONB vs normalize tablolar: karar verin ve göç edin

Asıl problem: hızlı hareket etmek ama kendini köşeye sıkıştırmamak

Gereksinimlerin her hafta değişmesi, yeni bir şey inşa ederken normaldir. Bir müşteri bir alan daha ister. Satış farklı bir iş akışı ister. Destek bir izleme kaydı ister. Veritabanınız sonunda bu değişikliklerin ağırlığını taşır.

Hızlı iterasyon sadece ekranları daha hızlı yayınlamak demek değildir. Alanları ekleyebilmek, yeniden adlandırmak ve kaldırmak; raporları, entegrasyonları veya eski kayıtları kırmadan yapmak demektir. Yeni sorulara da cevap verebilmek gerekir ("Geçen ay kaç siparişte teslimat notu eksikti?")—bunu her sorguyu tek seferlik bir script'e dönüştürmeden.

Bu yüzden JSONB ile normalize tablolar arasındaki seçim erken dönemde önemlidir. İkisi de işe yarar ve yanlış iş için kullanıldığında ikisi de acı verebilir. JSONB bugün neredeyse her şeyi saklayabildiğiniz için özgürlük gibi gelir. Normalize tablolar ise yapı zorladığı için daha güvenli hissedilir. Gerçek hedef, depolama modelini verinizin şu an ne kadar belirsiz olduğuna ve ne kadar hızlı güvenilir hâle gelmesi gerektiğine uyacak şekilde eşleştirmektir.

Ekipler yanlış modeli seçtiğinde belirtiler genelde açıktır:

• Basit sorular yavaş, dağınık sorgulara veya özel koda dönüşür.
• Aynı şeyi temsil eden iki kayıt farklı alan adları kullanır.
• İsteğe bağlı alanlar sonra zorunlu olur ve eski veriler uymaz.
• Kuralları (benzersiz değerler, zorunlu ilişkiler) uygulamak için geçici çözümler gerekir.
• Küçük değişikliklerden sonra raporlama ve dışa aktarmalar bozulur.

Pratik karar şudur: nerede esnekliğe ihtiyacınız var (ve bir süre tutarsızlığa katlanabilirsiniz), ve nerede yapıya ihtiyacınız var (çünkü veri para, operasyon veya uyumluluk sağlıyor)?

JSONB ve normalize tablolar, basitçe açıklama

PostgreSQL verileri klasik sütunlarda (text, number, date) saklayabilir. Ayrıca bir sütunda tüm bir JSON belgesini JSONB olarak saklayabilir. Fark "yeni vs eski" değildir; veritabanından ne garantisi beklediğinizdir.

JSONB anahtarları, değerleri, dizileri ve iç içe objeleri saklar. Her satırın aynı anahtarlara sahip olmasını, değerlerin her zaman aynı tipte olmasını veya referans verilen bir öğenin başka bir tabloda mevcut olmasını otomatik olarak garanti etmez. Kontroller ekleyebilirsiniz ama bunları kararlaştırıp uygulamanız gerekir.

Normalize tablolar verileri ne olduklarına göre ayrı tablolara bölüp ID'lerle bağlamaktır. Bir müşteri bir tabloda, bir sipariş başka tabloda olur ve her sipariş bir müşteriye işaret eder. Bu, çelişkilerle daha güçlü koruma sağlar.

Günlük işte ödünleşmeler nettir:

• JSONB: varsayılan olarak esnek, değiştirmesi kolay, sapmaya daha müsait.
• Normalize tablolar: değiştirmesi daha kasıtlı, doğrulaması daha kolay, tutarlı sorgulaması daha kolay.

Basit bir örnek destek ticket'larının özel alanlarıdır. JSONB ile yarın yeni bir alan ekleyebilirsiniz, migration gerekmez. Normalize tablolarla alan eklemek daha niyetli bir iştir, ama raporlama ve kurallar daha net olur.

JSONB hızlı iterasyon için ne zaman doğru araçtır

JSONB, en büyük riskiniz verinin yanlış şekillendirilmesi olduğunda güçlü bir seçimdir; katı kurallar uygulamak zorunda değilseniz. Ürününüz hâlâ iş akışını buluyorsa, her şeyi sabit tablolara zorlamak sizi sürekli migration'larla yavaşlatabilir.

Alanların haftalık değiştiği durumlar iyi bir işarettir. Örneğin pazarlamanın sürekli soru eklediği, etiketleri yeniden adlandırdığı veya adımları kaldırdığı bir onboarding formunu düşünün. JSONB, her gönderimi olduğu gibi saklamanıza izin verir; yarının versiyonu farklı görünse bile.

JSONB, ayrıca "bilinmeyenler" için uygundur: tam olarak anlamadığınız veya kontrol etmediğiniz veriler. Partnerlerden gelen webhook gövdelerini alıyorsanız, ham payload'ı JSONB'de saklamak yeni alanları hemen desteklemenizi sağlar ve hangi alanların birinci sınıf sütun olacağına sonra karar verebilirsiniz.

Erken aşamada yaygın kullanımlar: hızla değişen formlar, olay yakalama ve audit log'lar, müşteri başına ayarlar, özellik bayrakları ve deneyler. Özellikle veriyi çoğunlukla yazıyorsanız, bütün halinde geri okuyorsanız ve şekil hâlâ hareket ediyorsa işe yarar.

Bir koruyucu önlem çoğu kişinin beklediğinden daha faydalıdır: hangi anahtarları kullandığınıza dair kısa, ortak bir not tutun ki aynı alanın beş farklı yazımıyla karşılaşmayın.

Normalize tablolar neden uzun vadede daha güvenlidir

Veri "sadece bu özellik için" olmaktan çıkıp paylaşılan, sorgulanan ve güvenilen hâle geldiğinde normalize tablolar kazanır. İnsanlar kayıtları birçok şekilde dilimleyecekse (durum, sahip, bölge, zaman aralığı), sütunlar ve ilişkiler davranışı öngörülebilir ve optimize edilmesi kolay kılar.

Normalizasyon, kuralların veritabanı tarafından, uygulama kodunun "elinden gelen" çabası yerine uygulanması gerektiğinde de önemlidir. JSONB her şeyi saklayabildiği için, güçlü garantiler gerektiğinde bu tam tersine dönerek problem yaratır.

Şimdi normalize etmeniz gerektiğini gösteren işaretler

Genelde JSON-öncelikli modelden uzaklaşma zamanı şu maddelerden birkaçının doğru olmasıdır:

• Tutarlı raporlama ve panolara ihtiyacınız var.
• Zorunlu alanlar, benzersiz değerler veya diğer kayıtlara ilişkin özgül ilişkiler gibi kısıtlamalara ihtiyacınız var.
• Aynı veriyi birden fazla servis veya ekip okuyor ve yazıyor.
• Sorgular basit indeksleri iyi kullanamadığı için çok sayıda satır taramaya başlıyor.
• Düzenlenmiş veya denetlenen bir ortamdasınız ve kurallar kanıtlanabilir olmalı.

Performans sık rastlanan bir dönüm noktasıdır. JSONB ile filtreleme genellikle değerleri tekrar tekrar çıkarmak anlamına gelir. JSON path'leri için indeks ekleyebilirsiniz, ama gereksinimler genelde bakımı zor bir indeks yamalaması haline gelir.

Somut bir örnek

Bir prototip "müşteri istekleri"ni JSONB olarak saklıyor çünkü her istek tipi farklı alanlara sahip. Sonrasında operasyonlar öncelik ve SLA'ya göre filtrelenmiş bir kuyruk istiyor. Finans departmanı bölüme göre toplamlar istiyor. Destek müşteri ID ve durumun her istekte garanti edilmesini istiyor. İşte normalize tablolar parlıyor: ortak alanlar için net sütunlar, müşterilere ve ekiplere yabancı anahtarlar ve kötü verinin girmesini engelleyen kısıtlamalar.

30 dakikada kullanabileceğiniz basit karar çerçevesi

Büyük bir veritabanı teorisi tartışmasına ihtiyacınız yok. Hızlı, yazılı bir cevaba ihtiyacınız var: esneklik nereye değerli, sıkı yapı nereye değerli?

Bunu sistemi kuran ve kullanan kişilerle yapın (geliştirici, operasyon, destek ve belki finans). Amaç tek bir kazanan seçmek değil; ürününüzün her parçası için doğru uyumu seçmek.

5 adımlı kontrol listesi

1. En önemli 10 ekranınızı ve arkasındaki tam soruları listeleyin. Örnekler: "bir müşteri kaydını aç", "vadesi geçmiş siparişleri bul", "geçen ayın ödemelerini dışa aktar". Soruyu adlandıramıyorsanız, ona göre tasarlayamazsınız.

2. Her zaman doğru olması gereken alanları vurgulayın. Bunlar sert kurallar: durum, tutarlar, tarihler, sahiplik, izinler. Yanlış bir değer para kaybettirir veya destek yangını tetiklerse, genelde kısıtlı normal sütunlarda olmalıdır.

3. Sık değişenleri nadiren değişenlerden ayırın. Haftalık değişimler (yeni form soruları, partner'e özgü detaylar) JSONB için güçlü adaylardır. Nadiren değişen "çekirdek" alanlar normalize olmaya meyillidir.

4. Kullanıcıların UI'de hangi alanları arayıp filtrelemesi veya sıralaması gerektiğine karar verin. Kullanıcılar sürekli bir alan üzerinde filtreliyorsa, genelde birinci sınıf sütun (veya dikkatle indekslenmiş bir JSONB yolu) olarak tutmak daha iyidir.

5. Her alan için bir model seçin. Yaygın bir ayrım: çekirdek varlıklar ve iş akışları için normalize tablolar; ekstralar ve hızlı değişen meta veriler için JSONB.

Detaylara takılmadan performans temelleri

Hız genelde bir şeyden gelir: en yaygın sorularınızı ucuz hale getirmek. Bu ideolojiden daha önemlidir.

JSONB kullanıyorsanız, onu küçük ve öngörülebilir tutun. Birkaç ekstra alan sorun değil. Devasa, sürekli değişen bir blob ise indekslemesi zor ve kötüye kullanım için elverişlidir. Bir anahtarın var olacağını biliyorsanız (ör. "priority" veya "source"), anahtar adını ve değer tipini tutarlı tutun.

İndeksler sihir değildir. Okumaları hızlandırırken yazmaları yavaşlatır ve daha fazla disk kullanır. Sadece sık filtrelediğiniz veya join yaptığınız şeyleri indeksleyin ve sadece gerçekten sorguladığınız biçimde indeksleyin.

İndeksleme için pratik kurallar

• Status, owner_id, created_at, updated_at gibi yaygın filtreler için normal btree indeksleri koyun.
• İçinde sıkça arama yaptığınız bir JSONB sütunu için GIN indeksi kullanın.
• Bir veya iki sıcak JSON alanı için ifade (expression) indekslerini tercih edin (ör. (meta->>'priority')); tüm JSONB'yi indekslemek yerine.
• Sadece belirli bir dilim önemliyse partial indeksler kullanın (örneğin sadece status = 'open' olan satırlar).

JSONB içinde sayıları ve tarihleri string olarak saklamaktan kaçının. "10" "2"'den önce sıralanır ve tarih hesaplaması zorlaşır. Gerçek numeric ve timestamp tiplerini sütunlarda kullanın veya en azından JSON içinde sayıları sayı olarak saklayın.

Hibrit model genelde kazanır: çekirdek alanlar sütunlarda, esnek ekstralar JSONB'de. Örnek: id, status, owner_id, created_at sütunları olan bir operasyon tablosu ve opsiyonel cevaplar için meta JSONB.

Sonradan acı veren yaygın hatalar

JSONB erken dönemde özgürlük gibi gelir. Acı çoğunlukla aylar sonra, daha fazla insan veriye dokununca ve "ne iş görüyorsa olsun" yaklaşımı "bir şeyleri değiştiremiyoruz" haline gelince ortaya çıkar.

Bu kalıplar çoğu temizlik işine yol açar:

• JSONB'yi bir dökme alanı olarak kullanmak. Her ekip biraz farklı şekillerde veri saklarsa, her yerde özel parsing mantığı yazarsınız. Temel konvansiyonlar belirleyin: tutarlı anahtar adları, net tarih formatları ve JSON içinde küçük bir versiyon alanı.
• Temel varlıkları JSONB içinde saklamak. Müşterileri, siparişleri veya izinleri sadece blob olarak tutmak ilk başta basit görünür; sonra join'ler zorlaşır, kısıtlar uygulanması zorlaşır ve çoğalmalar ortaya çıkar. Kim/neyin/ne zaman olduğunu sütunlarda tutun; isteğe bağlı detayları JSONB'ye koyun.
• Göçü acil olana kadar düşünmemek. Hangi anahtarların var olduğunu, nasıl değiştiklerini ve hangilerinin "resmi" olduğunu takip etmezseniz ilk gerçek göç riskli olur.
• JSONB'nin otomatik olarak esnek ve hızlı olduğunu varsaymak. Kuralsız esneklik sadece tutarsızlıktır. Hız erişim desenlerine ve indekslere bağlıdır.
• Zaman içinde anahtarları değiştirerek analitiği bozmak. status'u state'e yeniden adlandırmak, sayıları stringe çevirmek veya zaman dilimlerini karıştırmak raporları sessizce bozar.

Somut bir örnek: bir ekip ticket'lar tablosu ve form cevaplarını tutan details JSONB alanı ile başlar. Sonra finans kategorilere göre haftalık döküm ister, operasyon SLA takibi ister ve destek ekip bazlı "açık" panolar ister. Kategoriler ve zaman damgaları anahtarlar ve formatlar arasında sürüklenirse, her rapor tek seferlik bir sorguya dönüşür.

Prototip kritik hale geldiğinde bir göç planı

Prototip maaş, stok veya müşteri desteği yönetmeye başladığında "veriyi sonra düzeltiriz" yaklaşımı kabul edilemez olur. En güvenli yol, küçük adımlarla göç etmek; yeni yapı doğrulanırken eski JSONB verisinin çalışmaya devam etmesini sağlamaktır.

Aşamalı yaklaşım riski büyük bir toplu yeniden yazımdan kaçınır:

• Hedefi önce tasarlayın. Hedef tabloları, birincil anahtarları ve adlandırma kurallarını yazın. Hangi şeylerin gerçek varlık olduğu (Customer, Ticket, Order) ve hangi alanların esnek kalacağına karar verin.
• Eski verinin yanına yeni tablolar oluşturun. JSONB sütununu tutun, normalize tabloları ve indeksleri paralel olarak ekleyin.
• Partiler halinde backfill ve doğrulama yapın. JSONB alanlarını yeni tablolara parça parça taşıyın. Satır sayıları, zorunlu alanların null olmaması ve rastgele kontrollerle doğrulayın.
• Okumaları yazmalardan önce değiştirin. Sorguları ve raporları önce yeni tablolardan okumaya güncelleyin. Çıktılar uyuştuğunda yeni değişiklikleri normalize tablolara yazmaya başlayın.
• Kilitleyin. JSONB'ye yazmayı durdurun, sonra eski alanları silin veya dondurun. Kötü verinin geri gelmemesi için kısıtlar ekleyin (yabancı anahtarlar, benzersiz kurallar).

Kesin geçişten önce:

• İki yolu bir hafta çalıştırın (eski ve yeni) ve çıktıları karşılaştırın.
• Yavaş sorguları izleyin ve gerekirse indeks ekleyin.
• Bir geri alma planı hazırlayın (feature flag veya konfigürasyon anahtarı).
• Yazma anahtarının tam zamanını ekibe bildirin.

Karar vermeden önce hızlı kontroller

Yaklaşımı kilitlemeden önce bir gerçeklik kontrolü yapın. Bu sorular değişiklik hâlindeyken çoğu gelecekteki baş ağrısını yakalar.

Sonuçların çoğunu belirleyen beş soru

• Şu anda (veya bir sonraki sürümde) benzersizlik, zorunlu alanlar veya sıkı tipler gerekiyor mu?
• Kullanıcıların UI'de filtrelemesi ve sıralaması gereken hangi alanlar var (arama, durum, sahip, tarihler)?
• Yakında panolar, dışa aktarmalar veya "finansa/operasyona gönder" raporları gerekecek mi?
• Yeni bir ekip arkadaşına veri modelini 10 dakikada, lafı dolaştırmadan anlatabiliyor muyuz?
• Bir göç iş akışı bir şeyi kırarsa geri alma planımız nedir?

İlk üçe "evet" diyorsanız normalize tablolara veya en azından hibrite (çekirdek alanların normalize edilmesi, uzun kuyruk özniteliklerin JSONB'de kalması) eğilimlisiniz demektir. Eğer tek "evet" son sorudaysa, asıl sorun süreçtir, şema değil.

Basit bir pratik kural

Şekli belirsiz olan veriler için JSONB kullanın; ama her zaman ihtiyaç duyacağınız küçük bir kararlı alan setini isimlendirebiliyorsanız (id, owner, status, created_at gibi) bunları gerçek sütunlarda tutun. İnsanlar tutarlı filtrelemeye, güvenilir dışa aktarmalara veya sıkı doğrulamaya bağımlı olduğunda "esneklik" maliyeti hızla artar.

Örnek: esnek bir formdan güvenilir bir operasyon sistemine

Haftada değişen bir müşteri destek giriş formunu hayal edin. Bir hafta "device model" eklersiniz, sonraki hafta "refund reason" eklenir, sonra "priority"yi "urgency" olarak yeniden adlandırırsınız. Başlangıçta form payload'unu tek bir JSONB sütununa koymak mükemmel gelir. Değişiklik yapmadan yayınlarsınız.

Üç ay sonra yöneticiler "urgency = high ve device model iPhone ile başlıyorsa" gibi filtreler, müşteri tier'ına göre SLA'lar ve haftalık olarak aynı şekilde eşleşmesi gereken raporlar ister.

Başarısızlık modu öngörülebilir: birisi "Bu alan nereye gitti?" diye sorar. Eski kayıtlar farklı anahtar adı kullanmış, değer tipi değişmiş ("3" vs 3) veya alanın yarısı kayıt için hiç yoktur. Raporlar özel vak'a vak'a sorgularla dolup taşar.

Pratik orta yol hibrit tasarımdır: kararlı, iş açısından kritik alanları gerçek sütunlar olarak tutun (created_at, customer_id, status, urgency, sla_due_at) ve yeni veya nadir alanlar için JSONB genişletme alanı bırakın.

Düşük müdahaleli bir zaman çizelgesi işe yarar:

• 1. Hafta: Filtrelenmesi ve raporlanması gereken 5–10 alan seçin. Sütunları ekleyin.
• 2. Hafta: Yeni sütunları mevcut JSONB'den önce yeni kayıtlardan sonra eski kayıtlara doğru backfill yapın.
• 3. Hafta: Yeni kayıtların hem sütunları hem JSONB'yi doldurduğu geçici çift yazmayı devreye alın.
• 4. Hafta: Okumaları ve raporları sütunlara taşıyın. JSONB'yi sadece ekstralar için bırakın.

Sonraki adımlar: karar verin, belgeleyin ve geliştirmeye devam edin

Hiçbir şey yapmazsanız karar sizin yerinize verilir. Prototip büyür, kenarlar sertleşir ve her değişiklik riskli hissettirir. Daha iyi olan küçük bir yazılı karar vermek ve sonra inşa etmeye devam etmektir.

Uygulamanızın hızlıca cevaplaması gereken 5–10 soruyu listeleyin ("bu müşterinin tüm açık siparişlerini göster", "e-posta ile kullanıcı bul", "aylık gelir raporu"). Her birinin yanına bozamayacağınız kısıtları yazın (benzersiz e-posta, zorunlu durum, geçerli toplamlar). Sonra net bir sınır çizin: sık değişen ve nadiren filtrelenen alanları JSONB'de tutun; aradığınızda, sıraladığınızda, join yaptığınızda veya her seferinde doğrulamanız gerekenleri sütunlara/tablolarına yükseltin.

No-code bir platform kullanıyorsanız bu ayrımı zaman içinde yönetmek daha kolay olabilir. Örneğin AppMaster (appmaster.io) PostgreSQL tablolarını görsel olarak modellemenize ve gereksinimler değiştikçe altyapıyı ve uygulamaları yeniden üretmenize izin vererek yineleyici şema değişimlerini ve planlı göçleri daha az sancılı hale getirebilir.