SQL ve NoSQL Veritabanı Farkı Nedir?

Her yazılım uygulamasının kalbinde veriyi güvenli bir şekilde saklayan, işleyen ve milisaniyeler içinde sorgulanmasını sağlayan veritabanı yönetim sistemi (DBMS) yer alır. Bir yazılım projesinde uygulama kodunu veya kullanıcı arayüzünü sonradan yeniden yazmak mümkündür; ancak canlıda terabaytlarca veriye ulaşmış bir veritabanı mimarisini değiştirmek en zor, en maliyetli ve en riskli mühendislik operasyonudur. Bu nedenle sistem tasarımının başında SQL (İlişkisel) ve NoSQL (İlişkisel Olmayan) veritabanı farkı konusunu doğru analiz etmek, projenin gelecekteki performansını, veri bütünlüğünü ve ölçeklenebilirliğini doğrudan belirler. Uygulama ve yazılım dünyasında PostgreSQL ve MySQL gibi ilişkisel devler ile MongoDB, Redis, Cassandra ve Elasticsearch gibi NoSQL çözümleri arasındaki seçim; bir "hangisi daha iyi" tartışması değil, veri modelinize, sorgu desenlerinize ve tutarlılık (Consistency) gereksinimlerinize en uygun motoru seçme mühendisliğidir. Bu kapsamlı rehberde; ACID ve BASE teoremlerinden CAP teoremine, B-Tree ve LSM-Tree indeksleme veri yapılarından yatay bölümleme (Sharding) ve Polyglot Persistence mimarisine kadar tüm detayları inceliyoruz.

SQL (İlişkisel Veritabanı - RDBMS) Nedir ve Nasıl Çalışır?

1970 yılında IBM araştırmacısı Edgar F. Codd'un ilişkisel cebir makalesiyle temelleri atılan İlişkisel Veritabanı Yönetim Sistemleri (RDBMS / SQL), verileri önceden katı kurallarla tanımlanmış şemalara (Strict Schema) sahip Tablolar (Satırlar/Tüpler ve Sütunlar/Nitelikler) halinde saklayan sistemlerdir. PostgreSQL, MySQL, Oracle Database ve Microsoft SQL Server bu ailenin en güçlü temsilcileridir.

SQL veritabanlarının temel tasarım felsefesi Veri Normalizasyonu (Normalization - 1NF, 2NF, 3NF, BCNF) ilkesine dayanır. Veri tekrarını (redundancy) ve güncelleme anomalilerini önlemek için veriler mantıksal tablolara bölünür ve tablolar birbirine Birincil Anahtar (Primary Key - PK) ve Yabancı Anahtar (Foreign Key - FK) kısıtlamalarıyla bağlanır (Referential Integrity). Örneğin bir müşterinin adresi 50 farklı sipariş satırında tekrar tekrar yazılmaz; Addresses tablosunda tek bir kez tutulur ve sipariş sorgulanırken JOIN operatörü ile çalışma anında birleştirilir.

ACID Teoremi: Finansal ve Kritik Verilerin Sarsılmaz Garantisi

Bankacılık, muhasebe, stok yönetimi ve ödeme sistemlerinde SQL veritabanlarının vazgeçilmez olmasının ana nedeni ACID işlem (transaction) garantileridir:

• Atomicity (Atomiklik - Ya Hep Ya Hiç): Bir para transferi işleminde A hesabından 1.000 TL düşülmesi ve B hesabına 1.000 TL eklenmesi tek bir atomik birimdir. İkinci adımda sunucu elektriği kesilse bile, veritabanı geri alma günlüğü (Undo/Write-Ahead Log - WAL) sayesinde ilk adımı geri alır; para asla havada kaybolmaz.
• Consistency (Tutarlılık): Her işlem veritabanını geçerli bir durumdan başka bir geçerli duruma taşır. Tanımlanan hiçbir şema kuralı, veri tipi, UNIQUE veya CHECK (balance >= 0) kısıtlaması ihlal edilemez.
• Isolation (İzolasyon): Aynı anda aynı satırı güncellemeye çalışan binlerce eşzamanlı işlemin birbirinin ara durumlarını (Dirty Read, Non-Repeatable Read, Phantom Read) görmesi engellenir. Modern PostgreSQL gibi motorlar bunu okuyanların yazanları bloklamadığı MVCC (Multi-Version Concurrency Control) mimarisiyle ve Read Committed, Repeatable Read, Serializable izolasyon seviyeleriyle yönetir.
• Durability (Kalıcılık): İşlem COMMIT edildiği andan itibaren, 1 milisaniye sonra işletim sistemi çökse dahi veri kalıcı diske (WAL / Redo Log) yazıldığı için kesinlikle korunur.

NoSQL ("Not Only SQL") Veritabanı Nedir ve Neden Doğdu?

2000'li yılların ikinci yarısında sosyal medya, IoT sensör ağları ve küresel bulut platformlarının yükselişiyle birlikte iki büyük sorun ortaya çıktı: Birincisi, saniyede milyonlarca yazma isteğini tek bir merkezi SQL sunucusuna (Master Node) sığdırmak donanımsal olarak imkansız hale geldi. İkincisi, sürekli değişen yarı-yapılandırılmış (semi-structured) verileri katı tablo sütunlarına zorlamak ve milyonlarca satırlık tablolarda ALTER TABLE veya çoklu JOIN çalıştırmak sistemleri kilitliyordu.

NoSQL (Not Only SQL) veritabanları; esnek şema (Schema-less / Dynamic Schema) yapısı sunmak, ilişkisel JOIN maliyetini ortadan kaldırmak ve ucuz sunucular eklenerek yatayda sınırsız ölçeklenebilmek (Horizontal Scaling / Auto-Sharding) amacıyla tasarlanmış dağıtık veri saklama motorlarıdır. NoSQL tek bir teknoloji değil, dört farklı veri modelini kapsayan bir şemsiyedir:

NoSQL Veritabanlarının 4 Ana Kategorisi

1. Belge Tabanlı (Document Databases - MongoDB, Couchbase, AWS DocumentDB): Verileri tablo satırları yerine JSON/BSON (Binary JSON) belgeleri olarak saklar. Bir siparişe ait müşteri bilgisi, teslimat adresi ve sipariş kalemleri 3 ayrı tabloya bölünmek yerine tek bir iç içe geçmiş (embedded) JSON belgesi içinde bir arada tutulur. Böylece JOIN yapmadan tek bir disk okumasında tüm nesne belleğe alınır.
2. Anahtar-Değer Tabanlı (Key-Value Stores - Redis, Amazon DynamoDB, Etcd): En hızlı ve en basit veri modelidir. Benzersiz bir anahtar (Key) karşılığında bir değer (Value) doğrudan RAM veya SSD üzerinde saklanır. O(1) zaman karmaşıklığıyla mikrosaniye mertebesinde yanıt verir; önbellekleme (Caching), kullanıcı oturumları (Session), alışveriş sepeti ve liderlik tabloları için standarttır.
3. Geniş Sütunlu (Wide-Column / Column-Family - Apache Cassandra, ScyllaDB, HBase): Verileri satır bazlı değil, sütun aileleri ve bölüm anahtarları (Partition Key) bazında dağıtık halkalar (Ring Architecture) üzerinde saklar. Tek bir merkez (Master) yoktur; her düğüm eşit (Peer-to-Peer) olduğu için saniyede milyonlarca yazma işlemini sıfır kesintiyle (Zero Single Point of Failure) karşılar. IoT telemetri verileri, mesajlaşma geçmişleri (Discord/WhatsApp) ve zaman serisi logları için idealdir.
4. Graf Veritabanları (Graph Databases - Neo4j, Amazon Neptune): Verileri Düğümler (Nodes) ve onları birbirine bağlayan Kenarlar/İlişkiler (Edges) olarak modeller. İlişkisel veritabanlarında 5-6 seviye derinliğindeki "Arkadaşımın arkadaşının satın aldığı ürünler" sorgusu yüzlerce JOIN nedeniyle çökerken, Graf veritabanları Index-Free Adjacency sayesinde milyonlarca bağlantıyı milisaniyeler içinde gezer. Sahtekarlık tespiti (Fraud Detection) ve öneri motorlarında kullanılır.

SQL Tablo Şeması vs NoSQL (MongoDB) Belge Modeli Karşılaştırması

Bir ürün kataloğu tasarlarken elektronik kategorisindeki bir dizüstü bilgisayarın ramKapasi ve ekranKarti özellikleri varken, giyim kategorisindeki bir gömleğin beden ve kumasTipi özellikleri bulunur. SQL'de bu değişken özellikleri modellemek için karmaşık EAV (Entity-Attribute-Value) tabloları gerekirken, NoSQL belge veritabanında her ürün kendi polimorfik JSON şemasıyla tek bir koleksiyonda doğal olarak saklanır:

// MongoDB (NoSQL) Ürün Belgesi - Tek Belgede Gömülü (Embedded) Veri Modeli
{
  "_id": "prod_98234",
  "sku": "LAPTOP-PRO-16",
  "title": "UltraBook Pro 16 İnç İş İstasyonu",
  "price": 64999.00,
  "currency": "TRY",
  "attributes": {
    "cpu": "14 Çekirdek ARM",
    "ram_gb": 32,
    "storage_tb": 1
  },
  "warehouse_stock": [
    { "city": "İstanbul", "quantity": 45 },
    { "city": "Ankara", "quantity": 12 }
  ]
}

CAP Teoremi ve BASE Modeli: Dağıtık Sistemlerin Fizik Kuralları

Bilgisayar bilimci Eric Brewer tarafından ortaya konan CAP Teoremi, ağ üzerinden birbirine bağlı birden fazla sunucudan oluşan dağıtık bir veri sisteminin aynı anda aşağıdaki üç özelliği birden %100 sağlayamayacağını, bir ağ bölünmesi (Network Partition) anında ikisinden birini seçmek zorunda olduğunu kanıtlar:

• C - Consistency (Tutarlılık): Kümedeki hangi sunucuya (node) okuma isteği atarsanız atın, her zaman en son yazılmış güncel veriyi alma garantisidir.
• A - Availability (Erişilebilirlik): Bazı sunucular çökmüş veya bağlantısı kopmuş olsa bile, çalışan her sunucunun gelen her isteğe (hata dönmeden) bir yanıt dönebilme garantisidir.
• P - Partition Tolerance (Bölünme Toleransı): Veri merkezleri veya sunucular arasındaki ağ kablolarında kopma/gecikme yaşansa bile sistemin çalışmaya devam etmesidir. Dağıtık sistemlerde ağ kopmaları kaçınılmaz olduğu için P zorunludur; dolayısıyla tercih CP (Tutarlılık öncelikli; örn. MongoDB, HBase, Redis Cluster) ile AP (Erişilebilirlik öncelikli; örn. Cassandra, DynamoDB) arasında yapılır.

AP odaklı NoSQL sistemler katı ACID yerine BASE modelini benimser: Basically Available (Temelde her zaman erişilebilir), Soft State (Veri durumu dış girdi olmadan bile arka plandaki senkronizasyonla zaman içinde değişebilir) ve Eventual Consistency (Nihai Tutarlılık) (Yazılan bir veri milisaniyeler içinde tüm kopyalara yayılır ve sistem sonunda tutarlı hale gelir).

Kaputun Altındaki Mühendislik: B-Tree vs LSM-Tree İndeksleme

SQL ve NoSQL veritabanlarının okuma ve yazma hızlarındaki fark, veriyi diske yazarken kullandıkları veri yapılarından kaynaklanır:

• B-Tree / B+Tree (PostgreSQL, MySQL InnoDB): Verileri dengeli ağaç (Balanced Tree) sayfalarında (genellikle 8 KB veya 16 KB bloklar) sıralı olarak tutar. Okuma (Read) ve aralık sorgularında (WHERE price BETWEEN 100 AND 500) O(log N) karmaşıklığıyla olağanüstü hızlıdır. Ancak her yeni rastgele yazma işleminde (Random I/O) diskteki ilgili ağaç sayfasının bulunup güncellenmesi ve ağacın yeniden dengelenmesi gerektiği için aşırı yoğun yazma yüklerinde disk I/O darboğazı oluşabilir.
• LSM-Tree (Log-Structured Merge-Tree - Cassandra, ScyllaDB, RocksDB): Yoğun yazma (Write-Heavy) iş yükleri için tasarlanmıştır. Gelen yeni veri diskte rastgele bir yer aranmadan anında sıralı olarak (Sequential I/O) CommitLog dosyasına ve RAM'deki MemTable ağacına eklenir. MemTable dolduğunda diske değiştirilemez (Immutable) SSTable (Sorted String Table) olarak tek seferde yazılır. Bu sayede LSM-Tree tabanlı NoSQL veritabanları B-Tree'ye kıyasla çok daha yüksek yazma hızlarına ulaşır; okuma hızını korumak için ise bellekte Bloom Filter yapılarını kullanır.

Ölçeklendirme Mimarisi: Dikey Ölçekleme (Scale-Up) vs Yatay Sharding (Scale-Out)

Geleneksel SQL veritabanları tek bir sunucu üzerinde çalışmak üzere tasarlandığı için trafik arttığında genellikle Dikey Ölçekleme (Vertical Scaling / Scale-Up) yapılır; yani sunucunun CPU çekirdeği 16'dan 64'e, RAM'i 64 GB'tan 512 GB'a çıkarılır ve okuma yükünü dağıtmak için Read Replicas (Okuma Kopyaları) eklenir. Ancak tek bir ana sunucunun (Primary/Master) yazma kapasitesinin fiziksel bir üst sınırı vardır.

NoSQL veritabanları ise doğuştan Yatay Ölçekleme (Horizontal Scaling / Sharding) mimarisine sahiptir. Veriler bir Shard Key / Partition Key (örneğin CustomerID veya CountryCode) üzerinden Tutarlı Özetleme (Consistent Hashing) algoritmasıyla 50 farklı sunucuya otomatik olarak bölünür. Böylece hem okuma hem de yazma kapasitesi sunucu ekledikçe doğrusal olarak artar. Günümüzde CockroachDB, Google Cloud Spanner ve TiDB gibi NewSQL (Dağıtık SQL) veritabanları ise hem yatay Sharding ölçeklenebilirliğini hem de tam ACID SQL garantilerini bir arada sunmaktadır.

Polyglot Persistence: Modern Sistemlerde SQL ve NoSQL Nasıl Birlikte Kullanılır?

Modern Headless Commerce ve mikroservis API mimarilerinde artık tüm sistem için tek bir veritabanı seçilmez; bunun yerine her mikroservisin kendi iş yüküne en uygun veritabanı motorunu kullandığı Polyglot Persistence (Çok Dilli Kalıcılık) yaklaşımı uygulanır. Örneğin yüksek trafikli bir bulut teknolojisi ve SaaS e-ticaret platformunda veri katmanı şu şekilde paylaştırılır:

• Sipariş, Ödeme ve Muhasebe Servisi (PostgreSQL - SQL): Kuruşuna kadar tam finansal doğruluk ve ACID transaction bütünlüğü gerektiği için ilişkisel veritabanında tutulur.
• Ürün Kataloğu ve İçerik Yönetimi (MongoDB - Document NoSQL): Binlerce farklı kategoriye ait esnek ürün özellikleri ve hızlı JSON okuma performansı için belge tabanlı veritabanında saklanır.
• Alışveriş Sepeti ve Oturum Yönetimi (Redis - Key-Value NoSQL): Kullanıcının sepete eklediği ürünler milisaniye altı hızda okunup yazılmak ve belirli bir süre (TTL) sonunda otomatik silinmek üzere bellek içi (In-Memory) veritabanında tutulur.
• Tam Metin Arama ve Filtreleme (Elasticsearch / OpenSearch): Yazım hatalarına duyarlı (Fuzzy Search) ürün arama ve çok boyutlu filtreleme (Faceted Search) işlemleri ters indeks (Inverted Index) motorunda yürütülür.

Ayrıca eski monolitik SQL şemalarının analiz edilip mikroservis veritabanlarına ayrıştırılmasında yapay zeka destekli tersine mühendislik (REA), kurumsal iç panellerin hem SQL hem NoSQL veritabanlarına kodsuz bağlanmasında No-Code uygulama geliştirme platformları ve değiştirilemez merkeziyetsiz kayıt defterlerinde Web3 ve merkezsiz web depolama protokolleri (IPFS, Arweave) hibrit veri mimarisini tamamlar.

SQL (İlişkisel) ve NoSQL Veritabanı Karşılaştırma Tablosu

Projeniz için veritabanı seçimi yaparken SQL ve NoSQL dünyasının temel mühendislik farklarını aşağıdaki tabloda karşılaştırmalı olarak inceleyebilirsiniz:

Karşılaştırma Kriteri	SQL (İlişkisel Veritabanları)	NoSQL (İlişkisel Olmayan Veritabanları)
Veri Modeli	Satır ve Sütunlardan oluşan İlişkisel Tablolar	Belge (JSON), Anahtar-Değer, Geniş Sütun veya Graf
Şema Yapısı (Schema)	Katı ve Önceden Tanımlı (Strict Schema)	Dinamik ve Esnek (Schema-less / Schema-on-Read)
İşlem Garantisi	Tam ACID Garantisi (Güçlü Tutarlılık)	Genellikle BASE Modeli (Ayarlanabilir / Nihai Tutarlılık)
Veri Birleştirme (JOIN)	Güçlü ve Doğal (Çoklu tablo SQL JOIN desteği)	Sınırlı veya Yok (Veri denormalize/gömülü saklanır)
Ölçeklendirme Yöntemi	Öncelikle Dikey (Scale-Up) + Read Replicas	Doğuştan Yatay Ölçekleme (Auto-Sharding / Scale-Out)
İndeksleme Motoru	Çoğunlukla B-Tree / B+Tree (Okuma odaklı)	B-Tree (MongoDB) veya LSM-Tree (Cassandra/ScyllaDB)
Popüler Örnekler	PostgreSQL, MySQL, Oracle, MS SQL Server	MongoDB, Redis, Cassandra, Elasticsearch, Neo4j
En İdeal Kullanım Alanı	Finans, Muhasebe, ERP, Sipariş/Ödeme, İlişkisel CRM	Büyük Veri, IoT, Gerçek Zamanlı Analitik, Katalog, Oyun

Sıkça Sorulan Sorular (SSS)

1. PostgreSQL içinde JSONB desteği varken neden hala MongoDB gibi bir NoSQL veritabanı kullanılsın?

PostgreSQL'in JSONB veri tipi ve GIN indeksleme yeteneği gerçekten de birçok belge tabanlı (Document) kullanım senaryosunu tek bir veritabanında çözebilir ve orta ölçekli projelerde ayrı bir MongoDB kurma ihtiyacını ortadan kaldırır. Ancak veri hacmi onlarca terabaytı aştığında ve yazma yükünü coğrafi olarak dağıtılmış onlarca sunucuya yerleşik (native) Auto-Sharding ile bölmek gerektiğinde, MongoDB veya Cassandra gibi dağıtık NoSQL mimarileri operasyonel olarak çok daha kolay yatay ölçeklenir.

2. NoSQL veritabanları ACID işlemleri (Transaction) hiç desteklemez mi?

Bu bilgi artık güncel değildir. İlk nesil NoSQL veritabanları yalnızca tek bir belge (Single-Document) düzeyinde atomiklik sunuyordu; ancak MongoDB 4.0+ sürümünden itibaren çoklu belge ve çoklu koleksiyon düzeyinde tam ACID Transactions desteği kazanmıştır. Yine de NoSQL'de çoklu belge transaction'ları ilişkisel veritabanlarına göre daha fazla performans maliyeti yarattığı için veri modelinin mümkün olduğunca tek belge içinde (embedded) kapsanması önerilir.

3. Veri tekrarı (Denormalization) NoSQL'de neden bir hata değil, tasarım tercihidir?

SQL dünyasında geliştirildiği 1970'lerde disk depolama alanı son derece pahalıydı, bu yüzden veriyi tekrar etmemek (Normalizasyon) birinci öncelikti. Günümüzde ise bulut disk alanı çok ucuz, ancak işlemci (CPU) zamanı ve ağ gecikmesi (Latency) çok pahalıdır. NoSQL mimarisinde okuma sırasında maliyetli JOIN işlemleri yapmamak için veri bilinçli olarak tekrarlı (denormalize) kaydedilir; böylece sorgu performansı maksimuma çıkarılır.

4. Redis bir ana veritabanı (Primary Database) olarak kullanılabilir mi?

Redis verileri öncelikle RAM üzerinde tuttuğu için mikrosaniye hızındadır ve RDB (Anlık Görüntü) ile AOF (Append-Only File) mekanizmaları sayesinde veriyi diske de yedekleyebilir. Ancak RAM maliyeti SSD diske göre çok yüksek olduğu ve karmaşık ilişkisel sorgulara izin vermediği için Redis genellikle tek başına ana veritabanı olarak değil; PostgreSQL veya MongoDB'nin önünde Önbellek (Cache), dağıtık kilit (Distributed Lock) ve gerçek zamanlı kuyruk katmanı olarak kullanılır.

5. Yeni başlayan bir projede SQL mi yoksa NoSQL mi seçilmeli?

Çok özel bir büyük veri (IoT akışı, sosyal ağ grafiği veya saniyede yüz binlerce log yazımı) gereksiniminiz yoksa, yeni başlayan projelerin %90'ı için PostgreSQL gibi güçlü bir İlişkisel (SQL) veritabanı ile başlamak en güvenli mühendislik kararıdır. Çünkü uygulama büyürken sorgu ihtiyaçlarınız sürekli değişecektir ve ilişkisel bir şemada yeni raporlar/sorgular yazmak, yanlış modellenmiş bir NoSQL veritabanını sonradan düzeltmekten çok daha kolaydır.