NoSQL vs SQL Karşılaştırması: Doğru Veritabanını Seçme Rehberi

NoSQL vs SQL Karşılaştırması: Doğru Veritabanını Seçme Rehberi

Bir yazılım projesinde verdiğiniz en kalıcı karar, framework ve programlama dili değil; veritabanı seçimidir. Framework'ü altı ayda değiştirebilirsiniz, hatta dili. Ancak production'da terabaytlarca veri biriken bir veritabanını başka bir aileye taşımak 12-18 ay, bazen koca bir yeniden yazımı gerektirir. "İlk gün doğru tercih" en kıymetli mühendislik sermayesidir.

Bu rehber sıradan bir "MongoDB JSON, MySQL tablo" karşılaştırması değil. Bir mimarın 2020'lerin sonunda karşılaştığı gerçekçi seçim ortamını kapsıyor: dokuz farklı veritabanı ailesi (Relational, Document, Key-Value, Wide-Column, Graph, Time-Series, Search, Vector, NewSQL), iki rakip felsefe (ACID vs BASE), iki teorik çerçeve (CAP ve PACELC), bir karar matrisi (10+ pratik senaryo) ve polyglot persistence mimarisi. Sonunda kendi projeniz için "hangi tek veritabanı?" sorusuna değil, "hangi veritabanları, hangi rolde?" sorusuna cevap verebilecek bilgi setine sahip olacaksınız.

Buyukweb perspektifi: Bursa Tier 3 veri merkezimizdeki cPanel paylaşımlı hosting paketlerimizde varsayılan veritabanı motoru MariaDB 10.5'tir; bu paketler içinde MySQL/MariaDB-uyumlu uygulamalar (WordPress, OpenCart, PrestaShop, Joomla, Drupal, Laravel/Symfony uygulamaları) sorunsuz çalışır. Eğer PostgreSQL, MongoDB, Redis, Cassandra, Elasticsearch veya başka bir motor kurmak istiyorsanız — VDS sunucularımızda root erişiminiz tamdır; istediğiniz veritabanı kombinasyonunu kurarsınız. Buyukweb yönetilen NoSQL hizmeti vermez; veritabanı seçimi ve kurulum sorumluluğu sizdedir, biz altyapıyı sağlarız. Sorularınız için 0850 302 60 70 numaralı destek hattımıza ulaşabilirsiniz.

SQL Nedir? İlişkisel Modelin Bir Asra Yakın Hikayesi

Modern veritabanı dünyası 1970 yılında matematikçi Edgar F. Codd'un IBM'de yayınladığı "A Relational Model of Data for Large Shared Data Banks" makalesiyle başladı. Codd, verilerin hiyerarşik veya ağ tabanlı yapılarla saklanmasının yetersiz olduğunu, küme teorisine ve birinci dereceden mantığa dayalı bir model gerektiğini gösterdi. Bu makale ilişkisel veritabanı modelinin doğum belgesidir.

İlişkisel modelin temel kavramları:

• Tablo (relation) — satır ve sütunlardan oluşan iki boyutlu yapı
• Satır (tuple, record) — bir varlığın somut bir örneği
• Sütun (attribute) — varlığın bir özelliği, sabit veri tipi
• Anahtar (key) — primary key (PK), foreign key (FK), unique constraint
• Şema (schema) — tablo yapısının formal tanımı; schema-on-write uygulanır
• İlişki (relationship) — tablolar arası FK üzerinden bağlantı: 1:1, 1:N, N:N
• SQL (Structured Query Language) — Codd'un mantığını insan dostu bir sorgu diline dönüştüren standart; ilk taslak SEQUEL (Structured English Query Language) olarak 1974'te tanıtıldı, ANSI SQL standardı ilk kez 1986'da yayımlandı (SQL-86), sonra SQL-92, SQL:1999, SQL:2003, SQL:2008, SQL:2016, SQL:2023 gibi versiyonlar geldi.

Modern RDBMS örnekleri:

• MySQL — Oracle Corporation, açık kaynak (GPL), dünyanın en yaygın açık kaynak RDBMS'i. WordPress, Drupal, Joomla gibi PHP ekosisteminin doğal seçimi.
• MariaDB — MySQL'in 2009 fork'u; tamamen açık kaynak (GPL), MySQL ile binary uyumlu. Buyukweb cPanel paketlerinde varsayılan motor MariaDB 10.5.
• PostgreSQL — açık kaynak (PostgreSQL Lisansı), 1986'da Berkeley'de POSTGRES projesi olarak başladı, 1996'da SQL desteğiyle PostgreSQL adını aldı. Object-relational model: kullanıcı tanımlı tipler, JSON/JSONB, array, hstore, range type, full-text search, geometric type, pgvector ile vektör.
• SQLite — C kütüphanesi olarak gömülü çalışır, tek dosya. Mobil uygulamalar (iOS, Android), tarayıcılar, IoT cihazlar için baskın seçim.
• MSSQL (Microsoft SQL Server) — kurumsal kapalı kaynak, T-SQL dialect.
• Oracle Database — kurumsal kapalı kaynak, finans/telekom/devlet sektörlerinin baskın motoru.
• IBM Db2 — kurumsal mainframe ve dağıtık ortamlarda.

İlişkisel modelin güçlü tarafları:

1. ACID transaction garantisi (aşağıda detay): finans, e-ticaret, muhasebe için olmazsa olmaz.
2. SQL ile bildirimsel sorgu — "ne istediğinizi" söylersiniz, "nasıl getirileceğine" query planner karar verir. Optimizasyon motora bırakılır.
3. JOIN — bağlı veriler tek sorguda birleşir; ürün + sipariş + müşteri + adres aynı sonuç setinde.
4. Tutarlılık (consistency) garantisi — FK constraint sayesinde "yetim kayıt" oluşmaz.
5. Mature ekosistem — 50 yıl + GUI araç (DBeaver, pgAdmin, phpMyAdmin), ORM (Doctrine, Eloquent, SQLAlchemy, Prisma, TypeORM), backup araçları, monitoring (Percona Toolkit, pg_stat_statements), eğitim kaynağı.
6. Schema-on-write — veri girişi öncesi şema validasyonu; üretim sonrası "field bekledim, gelmedi" sürprizi yok.

NoSQL Nedir? "Not Only SQL" Hareketinin Doğuşu

2000'lerin sonlarında web ölçeği değişti. Google, Amazon, Facebook, Twitter gibi şirketler petabayt ölçeğinde, küresel coğrafi dağıtık, saniyede milyonlarca yazma isteyen sistemler kurmak zorunda kaldı. Geleneksel RDBMS bu ölçekte dikey scale (sunucuyu büyütme) sınırlarına çarpıyor, JOIN ve ACID maliyeti dağıtık ortamda sürdürülemiyordu.

2009'da San Francisco'da bir geliştirici toplantısında Johan Oskarsson "open source, distributed, non-relational databases" tartışmak için bir buluşma organize etti ve hashtag olarak #NoSQL kullandı. Terim hızla yapıştı.

"NoSQL" yanıltıcı bir isimdir. "No SQL" değil, "Not Only SQL" anlamına gelir. Yani: SQL'i reddetmez, sadece "her veri ilişkisel modelle çözülmez" der.

NoSQL'in temel ortak motifleri (her aile için aynı geçerlilikte değildir):

• Şema esnekliği (schema-on-read) — şema yok değil, sadece veri yazılırken zorlanmaz; uygulama katmanında doğrulanır.
• Yatay ölçekleme (horizontal scaling) — daha fazla sunucu ekleyerek kapasiteyi büyütme; sharding doğal.
• Distributed by default — replikasyon, partitioning, leader election çoğu motorda baştan beri var.
• Eventual consistency — global olarak hemen tutarlı değil, zaman içinde yakınsar; AP tarafı tercih edilir (CAP'a aşağıda dönüyoruz).
• Domain-specific veri modeli — document (JSON), key-value, wide-column, graph, time-series, search, vector; her birinin kendi sorgu dili ve idiomu var.

NoSQL SQL'i yok etmez; iyi tasarlanmış 2025 mimarileri polyglot persistence yaklaşımıyla her servis kendi DB ailesini seçer. Modern bir e-ticaret platformu PostgreSQL'i ana iş alanı için, Redis'i session/cache için, Elasticsearch'ü ürün araması için, MongoDB'yi log/event arşivi için, InfluxDB'yi performans metrikleri için kullanabilir.

ACID: İlişkisel Dünyanın Dört Tılsımlı Harfi

ACID, bir transaction'ın (işlem) hangi garantileri taşıması gerektiğini tanımlar. 1983'te Andreas Reuter ve Theo Härder kavramlaştırdı.

Atomicity (Atomiklik)

Bir transaction içindeki tüm işlemler ya hep ya hiç ilkesi ile uygulanır. Banka transferinde "100 TL hesap A'dan düşüldü" ama "100 TL hesap B'ye yatırıldı" başarısız olduysa, ilk işlem de geri alınır (rollback). Hiçbir zaman yarım iş kalmaz.

BEGIN;
UPDATE hesaplar SET bakiye = bakiye - 100 WHERE id = 1;
UPDATE hesaplar SET bakiye = bakiye + 100 WHERE id = 2;
COMMIT;  -- ya ikisi de uygulanır
-- ROLLBACK;  -- ya hiçbiri uygulanmaz

Consistency (Tutarlılık)

Veritabanı, transaction başlamadan geçerli (valid) bir durumda ise, transaction bittiğinde de geçerli (valid) bir durumda olmalıdır. Foreign key, unique constraint, check constraint, NOT NULL constraint gibi tanımlanmış invariant'lar her durumda korunur. Örneğin bir siparis kaydı silinmemiş bir musteri_id'ye işaret etmek zorundadır.

Isolation (İzolasyon)

Eşzamanlı çalışan transaction'lar birbirinden bağımsızmış gibi sonuç üretmelidir. Pratikte tam izolasyon performansa pahalıdır, bu yüzden SQL standardı dört izolasyon seviyesi tanımlar:

Seviye	Dirty Read	Non-Repeatable Read	Phantom Read	Performans
Read Uncommitted	Mümkün	Mümkün	Mümkün	En hızlı
Read Committed	Hayır	Mümkün	Mümkün	Hızlı (Postgres default)
Repeatable Read	Hayır	Hayır	Mümkün	Orta (MySQL InnoDB default)
Serializable	Hayır	Hayır	Hayır	En yavaş

• Dirty Read — başka transaction'ın henüz commit etmediği veriyi okumak
• Non-Repeatable Read — aynı satırı iki kez okuduğunuzda farklı değer görmek
• Phantom Read — aynı WHERE sorgusunu iki kez çalıştırdığınızda farklı satır sayısı görmek

PostgreSQL 12+ ve MySQL InnoDB her ikisi de MVCC (Multi-Version Concurrency Control) kullanır; izolasyon seviyeleri okuma kilidi yerine versiyonlama ile sağlanır. Detay için PostgreSQL kurulum rehberimiz ve MySQL yönetim rehberimize bakınız.

Durability (Kalıcılık)

Bir transaction COMMIT edildikten sonra, sunucu çökse bile veri kaybolmaz. Bu garanti WAL (Write-Ahead Log) veya redo log ile sağlanır: commit önce log dosyasına yazılır, sonra asenkron olarak data dosyalarına. Sunucu yeniden başlarken log'daki kayıtlar replay edilir.

BASE: NoSQL Felsefesinin Antitezi

BASE, ACID'in sıkı garantilerine karşıt bir esneklik felsefesidir. 2008'de Dan Pritchett "BASE: An Acid Alternative" makalesinde formalize etti.

• Basically Available — sistem genelde mevcut; bazı parçaları geçici olarak yanıt vermese de toplam kullanılabilir kalır.
• Soft state — sistem durumu zamanla değişebilir, dış etken olmasa bile (replikasyon, eventual consistency mekanizmaları).
• Eventually consistent — yazma sonrası okumanın eski değer dönebilir; ancak yeterli süre geçince tüm replikalar yakınsar.

BASE şu mantığa dayanır: internet ölçeğinde mükemmel tutarlılık imkansız, mükemmel kullanılabilirlik ise zorunlu. "Bir satışı saniyeler için yanlış stok göstermek" ile "siteyi tümüyle erişilmez kılmak" arasında bir e-ticaret tercihini ikincisinden yana yapmaz.

CAP Teoremi: Distributed Systems'in Üçgen Tuzağı

2000'de Berkeley'de Eric Brewer PODC konferansında konuştuğu bir tezi 2002'de Seth Gilbert ve Nancy Lynch matematiksel olarak ispatladı: CAP Teoremi.

Bir dağıtık sistem üç özellikten en fazla ikisini eş zamanlı garanti edebilir:

• C (Consistency) — tüm node'lar aynı anda aynı veriyi görür (linearizability)
• A (Availability) — her sorgu yanıt alır (başarılı ya da başarısız)
• P (Partition tolerance) — node'lar arası ağ bölünmesine rağmen sistem çalışır

Pratikte P seçimi opsiyonel değildir — internet, kablolar, switch'ler arıza yapar. Yani gerçek tercih C ile A arasındadır ağ bölünmesi anında:

CP Sistemler (Partition'da Consistency'i Koru)

Ağ bölünmesi anında tutarsız veri dönmektense yanıt vermemeyi seçer. Quorum-tabanlı veya leader-tabanlı sistemler tipiktir.

• MongoDB (single-primary replica set) — primary node bölünmüş tarafta kalırsa yazmalar reddedilir
• PostgreSQL (synchronous replication) — replika onaylamadıysa commit ilerlemez
• HBase — quorum kaybedildiyse okuma/yazma durur
• etcd, ZooKeeper, Consul — Raft consensus ile CP

AP Sistemler (Partition'da Availability'i Koru)

Ağ bölünmesi anında tutarsız veri dönmek pahasına yanıt vermeyi seçer. Sonradan replikalar uzlaşır (anti-entropy, vector clock, last-write-wins, CRDT).

• Apache Cassandra — tunable consistency (ONE, QUORUM, ALL) ile ayarlanabilir
• Riak — CRDT tabanlı eventual consistency
• CouchDB — multi-master, replikasyon esnek
• Eski Memcached — sade cache, atomic operasyon yok

CA Sistemler? (Yanılgı)

Bazı kaynaklar "CA" sistemleri (tek node RDBMS) listeler ama distributed system değiller. Tek bir PostgreSQL instance'ı dağıtık değildir, CAP teoremi onun için geçerli değil.

PACELC: CAP'in Eksik Yarısı

CAP teoremi sadece partition anını ele alır. 2010'da Daniel Abadi "PACELC" çerçevesini önerdi:

• P (Partition durumunda) → A vs C seçimi yap (CAP'in klasik kısmı)
• E (Else, normal durumda) → L (Latency) vs C (Consistency) seçimi yap

Yani partition olmayan normal koşullarda bile gecikme (latency) ile tutarlılık arasında bir trade-off vardır. Senkron replikasyon güçlü tutarlılık verir ama yazma gecikmesi artar; asenkron replikasyon hızlıdır ama eventual consistency.

Sistem	Partition'da	Normal'da	Etiket
MongoDB (defaults)	C	L	PC/EL
PostgreSQL (sync replikasyon)	C	C	PC/EC
Cassandra	A	L	PA/EL
Riak (eventual)	A	L	PA/EL
MySQL (sync replikasyon)	C	C	PC/EC
Cassandra ALL consistency	A	C	PA/EC (nadir)

PACELC, "Cassandra hızlı çünkü tutarlılık aramıyor; PostgreSQL yavaş çünkü tutarlılık arıyor" cümlesini formel düzlemde açıklar.

Veritabanı Aileleri Taksonomisi

Şimdi her ailenin tipik karakterini, popüler örneklerini ve hangi senaryoyu çözdüğünü inceleyelim.

1. Relational (RDBMS / SQL)

Karakter: Tablo + satır + sütun + FK + JOIN + ACID. Schema-on-write. SQL standardı. Genelde dikey scale; modern motorlar partitioning ve read replica ile yatay scale çalıştırır.

Popüler örnekler: MySQL, MariaDB, PostgreSQL, SQLite, MSSQL, Oracle, Db2.

Sorgu dili: SQL (ANSI standardı + vendor extension).

Ne zaman seçilir:

• Karmaşık ilişkisel veri (e-ticaret katalog + sipariş + ödeme + müşteri)
• Finansal, muhasebe, ERP, fatura uygulamaları (ACID şart)
• Raporlama ve analitik OLAP sorguları
• Olgun ekosistem (ORM, BI tools, migration framework)

Ne zaman seçilmez:

• Petabyte ölçek, küresel coğrafi dağıtık yazma
• Şemasız, çok değişken yapıda doc (tipik IoT event payload)
• Aşırı yüksek write throughput (saniyede milyonlar)

2. Document Database

Karakter: Veri JSON benzeri doküman olarak saklanır (BSON, JSON, XML). Her doküman kendi şemasına sahip olabilir; ilişkili veri embed (içine göm) veya reference (FK benzeri) edilir. Koleksiyon = tablo karşılığı.

Popüler örnekler:

• MongoDB — en yaygın document DB; BSON, aggregation pipeline, change stream, replica set, sharding. 4.0+ multi-document transaction (ACID).
• CouchDB — multi-master replikasyon, MapReduce view, mobil-friendly sync.
• RavenDB — .NET ekosisteminde sevilen, ACID transaction güçlü.

Sorgu dili: Her motor için kendi dialect — MongoDB için MQL (Mongo Query Language) + aggregation framework; CouchDB Mango query veya MapReduce view.

Document örneği (MongoDB):

{
  "_id": ObjectId("67323abc1234567890abcdef"),
  "isim": "Ahmet Yılmaz",
  "email": "[email protected]",
  "kayit_tarihi": ISODate("2026-01-15T08:30:00Z"),
  "adresler": [
    { "tip": "ev", "sehir": "Bursa", "posta_kodu": "16110" },
    { "tip": "is", "sehir": "İstanbul", "posta_kodu": "34010" }
  ],
  "tercihler": {
    "dil": "tr",
    "bildirim_kanali": "email",
    "tema": "dark"
  },
  "puan_bakiyesi": 1850
}

MongoDB temel kavramları:

• Koleksiyon (collection) — tablo karşılığı
• Doküman (document) — satır karşılığı (BSON formatında)
• Embedded vs Referenced — adresleri kullanıcı içine göm (embed) ya da ayrı koleksiyonda FK ile bağla (referans). Genelde 1:N için embed, N:N için referans.
• İndeks — single field, compound, multikey (array), text, geospatial (2dsphere), hashed, partial, TTL
• Aggregation pipeline — $match, $group, $lookup, $project, $unwind, $sort, $limit operatörleri ile veri akışı; SQL'in GROUP BY + JOIN + HAVING birleşimine benzer
• Replica set — primary + secondary node'lar; otomatik failover (Raft benzeri election)
• Sharding — shard key'e göre veriyi partition'lara böl, küresel scale-out
• Change Stream — real-time event subscription, CDC pattern için

Ne zaman seçilir:

• Şemanın projeyle birlikte evrildiği (startup, MVP) ortam
• Hiyerarşik / iç içe veri (kullanıcı profili + tercihler + adresler tek doc)
• Esnek katalog (ürün özellikleri her kategoride farklı)
• Real-time event/notification akışları
• CMS, blog, içerik yönetim

Ne zaman seçilmez:

• Karmaşık çoklu tablo JOIN'a ihtiyaç (MongoDB $lookup var ama optimize değil)
• Finansal cross-document transaction yoğun (4.0+ ACID var ama performansa pahalı)
• Yapılandırılmış raporlama (BI tools daha çok SQL bekler)

3. Key-Value Store

Karakter: Veri anahtar → değer çiftleri olarak saklanır. En basit ve en hızlı veri modeli. Genelde RAM'de tutulur, opsiyonel diske kalıcı yazma.

Popüler örnekler:

• Redis — açık kaynak (BSD lisansı; bazı sürümler RSAL/SSPL), in-memory data structure store. String, hash, list, set, sorted set, stream, bitmap, hyperloglog, geospatial veri yapıları.
• Memcached — sade, sadece string→string cache. Multithread.
• etcd — Raft consensus, Kubernetes'in metadata store'u.
• Riak — eventual consistent KV, vector clock + last-write-wins çatışma çözümü.

Sorgu dili: Genelde komut bazlı API — GET key, SET key value, INCR counter, EXPIRE key 60.

Redis veri yapıları:

SET kullanici:1842:isim "Ahmet Yılmaz"
GET kullanici:1842:isim
# "Ahmet Yılmaz"

HSET sepet:1842 urun:101 2 urun:202 1 urun:303 3
HGETALL sepet:1842
# urun:101 → 2, urun:202 → 1, urun:303 → 3

LPUSH bildirim:1842 "Sipariş kargoda"
LPUSH bildirim:1842 "Yeni indirim"
LRANGE bildirim:1842 0 9

ZADD lider_tablo 1850 "ahmet" 2400 "ayse" 1200 "mehmet"
ZREVRANGE lider_tablo 0 9 WITHSCORES

XADD olaylar:siparis * urun_id 101 musteri 1842 tutar 250
XREAD COUNT 100 STREAMS olaylar:siparis 0

PFADD ziyaretciler:gunluk:2026-05-11 "user-abc" "user-def" "user-ghi"
PFCOUNT ziyaretciler:gunluk:2026-05-11

Redis ek özellikler:

• Persistence — RDB (snapshot disk dump) + AOF (append-only file, write-ahead log benzeri). İki birleşim de kullanılabilir.
• Pub/Sub — kanal bazlı mesajlaşma; modern Streams daha güçlü ama Pub/Sub hâlâ kullanışlı
• Cluster — 16384 hash slot ile sharding; otomatik resharding
• Sentinel — yüksek erişilebilirlik (HA) için master/replica yönetimi
• Lua scripting — sunucuda atomic Lua script çalıştırma

Ne zaman seçilir:

• Session store (kullanıcı oturumu, JWT blacklist)
• Cache layer (RDBMS sorgu sonuçları, sayfalar, API response)
• Rate limiting (her IP için INCR + EXPIRE)
• Leaderboard / sıralama tablosu (sorted set)
• Real-time bildirim, chat presence
• Queue / job processing (Redis Streams, BullMQ, Sidekiq backend)

Ne zaman seçilmez:

• Birincil veri saklama, kompleks sorgu (RAM'de değil)
• Karmaşık aggregation, JOIN
• Tek anahtarda 1 GB üstü değer

4. Wide-Column Store

Karakter: Tablo + satır + sütun benzeri ama her satır farklı sütun kümesine sahip olabilir. Çok yüksek write throughput, petabyte ölçek, küresel coğrafi dağıtık. 2000'lerin sonunda büyük web ölçeği şirketlerin yayımladığı akademik makalelerin esinlenmesidir.

Popüler örnekler:

• Apache Cassandra — masterless ring topology, partition key + clustering column ile geniş satır modeli
• ScyllaDB — C++ ile yeniden yazılmış Cassandra; daha düşük latency, aynı protokol
• HBase — Hadoop ekosistemi, master-slave model

Sorgu dili: CQL (Cassandra Query Language) — SQL'e yüzeyde benzer ama farklı semantik (JOIN yok, ACID kısıtlı).

Cassandra temel kavramları:

• Ring topology — node'lar bir halka oluşturur, her node bir token aralığından sorumlu
• Partition key — verinin hangi node'a düşeceğini belirler
• Clustering column — partition içinde sıralama
• Tunable consistency — sorgu bazında ONE (en az 1 replika), QUORUM (çoğunluk), ALL (hepsi)
• Gossip protocol — node'lar birbirinin durumunu öğrenmek için broadcast
• Snitch — datacenter ve rack farkındalığı, network topology aware replication
• SSTable + Memtable + Commit log — LSM-tree tabanlı write path
• Repair — anti-entropy repair (nodetool repair) ile replikalar arası tutarlılık

Cassandra örneği:

CREATE KEYSPACE iot WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'dc1': 3
};

CREATE TABLE iot.sensor_okumalari (
  sensor_id text,
  okuma_zamani timestamp,
  sicaklik double,
  nem double,
  PRIMARY KEY ((sensor_id), okuma_zamani)
) WITH CLUSTERING ORDER BY (okuma_zamani DESC);

INSERT INTO iot.sensor_okumalari (sensor_id, okuma_zamani, sicaklik, nem)
VALUES ('sensor-1842', '2026-05-11 14:30:00', 23.5, 65.2);

SELECT * FROM iot.sensor_okumalari
WHERE sensor_id = 'sensor-1842'
  AND okuma_zamani > '2026-05-11 00:00:00'
LIMIT 100;

Ne zaman seçilir:

• Petabyte ölçek, milyarlarca satır, küresel coğrafi dağıtık
• Çok yüksek write throughput (saniyede yüz binler)
• Time-series benzeri veri (her satır timestamp odaklı)
• AP tarafı tercih ediliyor (tutarsız okuma kabul, sistem ayakta)

Ne zaman seçilmez:

• JOIN ihtiyacı (yok)
• Karmaşık aggregation
• Küçük ölçek (operasyonel yük abartılı)
• ACID transaction zorunlu

5. Graph Database

Karakter: Veri düğüm (node) ve ilişki (relationship) olarak modellenir. Düğümler özellik (property) taşır, ilişkiler yönlü ve türlü. N:N ilişkilerin derinlemesine traversal'ı için doğal.

Popüler örnekler:

• Neo4j — en popüler graph DB, Cypher sorgu dili, ACID transaction
• ArangoDB — multi-model (document + graph + KV)
• JanusGraph — TinkerPop ekosisteminde dağıtık graph, Gremlin sorgu dili
• Apache TinkerPop / Gremlin — graph traversal API standardı

Sorgu dili:

• Cypher (Neo4j) — pattern matching syntax: MATCH (n)-[r]->(m)
• Gremlin (TinkerPop) — fluent traversal API

Cypher örneği:

// Düğüm oluştur
CREATE (ahmet:Kullanici {isim: 'Ahmet', sehir: 'Bursa'})
CREATE (ayse:Kullanici {isim: 'Ayşe', sehir: 'Bursa'})
CREATE (mehmet:Kullanici {isim: 'Mehmet', sehir: 'İstanbul'})

// İlişki oluştur
CREATE (ahmet)-[:ARKADAS {tarih: '2024-03-15'}]->(ayse)
CREATE (ayse)-[:ARKADAS {tarih: '2025-01-10'}]->(mehmet)

// 2. derece arkadaş bul
MATCH (ben:Kullanici {isim: 'Ahmet'})-[:ARKADAS*2]->(arkadasinArkadasi)
WHERE NOT (ben)-[:ARKADAS]->(arkadasinArkadasi)
RETURN arkadasinArkadasi.isim

Ne zaman seçilir:

• Sosyal ağ (arkadaş ilişkisi, takipçi, mention)
• Knowledge graph (Wikipedia benzeri, semantik web)
• Recommendation engine ("bu ürünü alanlar şunu da aldı" graph traversal)
• Fraud detection (transaction graph, anomali pattern)
• Bilgi yönetimi (organizasyon hiyerarşisi, yetki/rol ilişkileri)
• Şebeke topolojisi (telekom, lojistik, supply chain)

Ne zaman seçilmez:

• Düz tablo veri (graph overhead gereksiz)
• Yüksek hacim write (graph DB write throughput RDBMS'ten düşük)

6. Time-Series Database (TSDB)

Karakter: Zaman damgalı veri için optimize edilmiş. Yüksek write throughput + range query by time + downsampling + retention policy.

Popüler örnekler:

• InfluxDB — açık kaynak (MIT), Flux/InfluxQL sorgu dili, TICK stack
• TimescaleDB — PostgreSQL extension; hypertable ile zaman tabanlı partitioning + SQL
• Prometheus — monitoring odaklı, pull-based, PromQL sorgu dili
• VictoriaMetrics — Prometheus uyumlu, daha verimli storage
• QuestDB — yüksek performans, SQL destekli
• OpenTSDB — HBase üzerinde TSDB

Karakteristik özellikler:

• Retention policy — eski verileri otomatik silme (1 yıllık raw, 1 yıllık 1 dakika ortalaması, sonsuz 1 saat ortalaması)
• Downsampling — yüksek çözünürlüklü veriyi düşük çözünürlüklü aggregate'e indirgeme
• Tag/label model — Prometheus benzeri metric + label kümesi
• Compression — Gorilla, Delta-of-Delta, XOR compression ile disk tasarrufu
• Continuous query — sürekli arka planda aggregate üretimi

Ne zaman seçilir:

• IoT sensör verisi (sıcaklık, nem, basınç, akış)
• Server/uygulama monitoring (CPU, RAM, disk, network metrikleri)
• Finansal tick data (saniyede yüzlerce fiyat)
• Web analytics (sayfa görüntüleme zaman serisi)
• DevOps observability (logging + metrics + tracing'in metrics ayağı)

Ne zaman seçilmez:

• İlişkisel sorgu (TSDB JOIN ya yok ya kısıtlı)
• Random access (TSDB sıralı time-range için optimize)

7. Search Engine

Karakter: Aslında "veritabanı" değil inverted index üzerinde full-text search yapan motor. Tokenization, analyzer, scoring (BM25, TF-IDF), faceted search, highlighting, geo search.

Popüler örnekler:

• Elasticsearch — açık kaynak (SSPL/Elastic Lisansı 7.10+ sonrası; Apache 2.0 fork olarak OpenSearch mevcut), Lucene tabanlı
• OpenSearch — Elasticsearch'ün açık kaynak fork'u (Apache 2.0)
• Apache Solr — Lucene tabanlı, eski okul, hâlâ canlı
• MeiliSearch — Rust, hızlı, modern UI; küçük-orta projeler için
• Typesense — MeiliSearch alternatifi
• Manticore Search — Sphinx fork'u

Lucene temel kavramları:

• Inverted index — kelime → dokümanlar listesi (tersine indeks)
• Tokenization — metni kelimelere (token) ayırma
• Analyzer — tokenization + lowercase + stop word + stemming + synonym
• Scoring — BM25 (default Elasticsearch 5+), TF-IDF (klasik)
• Faceted search — kategori sayıları (kategori: Telefon (250), Bilgisayar (180))
• Aggregation — terms, range, date histogram, geo distance

Ne zaman seçilir:

• E-ticaret ürün araması (filter, facet, sorting, fuzzy match)
• Log aggregation (ELK stack, EFK stack)
• İçerik / makale arama (haber sitesi, blog)
• Geospatial search (yakındaki restoran, lokasyon arama)
• Application Performance Monitoring (APM) trace search

Ne zaman seçilmez:

• Primary OLTP veritabanı (Elasticsearch eventual consistent, transaction yok)
• Karmaşık ilişkisel sorgu

8. Vector Database (AI / RAG)

Karakter: Embedding vektörlerini saklar ve benzerlik araması (cosine similarity, Euclidean distance, dot product) yapar. 2022 sonrası AI patlamasıyla (LLM, RAG, semantic search) öne çıktı.

Popüler örnekler:

• pgvector — PostgreSQL extension, vector(N) tipi + HNSW/IVFFlat index. Açık kaynak.
• Milvus — açık kaynak (Apache 2.0), büyük ölçek vector DB
• Qdrant — Rust, açık kaynak (Apache 2.0)
• Weaviate — Go, açık kaynak (BSD), graph + vector hibrit
• Chroma — Python-first, açık kaynak
• FAISS (Facebook AI Similarity Search) — kütüphane (DB değil), gömülü kullanım

Temel kavramlar:

• Embedding — metin/görüntü/ses → N boyutlu sayısal vektör (genelde 384, 768, 1024, 1536, 3072 boyut)
• Similarity metric — Cosine, Euclidean, Dot Product, Manhattan
• Index türü — Flat (exact), IVFFlat (clustering), HNSW (graph), LSH (locality sensitive hashing)
• Hybrid search — vector + keyword (BM25) kombinasyonu, daha iyi recall

pgvector örneği (PostgreSQL extension):

CREATE EXTENSION vector;

CREATE TABLE makaleler (
  id bigserial PRIMARY KEY,
  baslik text,
  icerik text,
  embedding vector(1536)
);

-- HNSW index
CREATE INDEX makaleler_embedding_hnsw ON makaleler
USING hnsw (embedding vector_cosine_ops);

-- Benzerlik araması
SELECT id, baslik, embedding <=> '[0.1, 0.2, ...]'::vector AS uzaklik
FROM makaleler
ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT 10;

Ne zaman seçilir:

• RAG (Retrieval Augmented Generation) — LLM context'ine ilgili doküman parçaları getirme
• Semantic search ("kelime değil, anlam ara")
• Recommendation (kullanıcı/ürün embedding benzerliği)
• Image / video benzerlik araması
• Chatbot context retrieval, memory store
• Anomaly detection (vector cluster dışı)

Ne zaman seçilmez:

• Tradisyonel keyword search (Lucene daha iyi)
• Yapılandırılmış sorgu (vector "benzeri" arama, exact match için değil)

pgvector pratiği: PostgreSQL kullanan bir uygulamanız varsa, AI / RAG için ayrı bir vektör veritabanı kurmaya gerek yok; CREATE EXTENSION vector; ile aynı veritabanına embedding tablosu eklersiniz. Tek operasyonel yük, tek backup, tek monitoring.

9. NewSQL — Modern Hibrit

Karakter: Geleneksel RDBMS'in ACID + SQL desteğini koruyarak NoSQL'in yatay scale ve dağıtık doğasını birleştirir. Raft / Paxos consensus, distributed transaction, geo-replication.

Popüler örnekler:

• CockroachDB — büyük hyperscaler distributed SQL araştırmalarından ilhamla doğmuş, açık kaynak (BSL), Postgres protokol uyumlu, Raft consensus
• TiDB — MySQL protokol uyumlu, HTAP (hybrid transactional + analytical), Raft consensus
• YugabyteDB — Postgres + Cassandra protokol uyumlu hibrit
• VoltDB — in-memory NewSQL, OLTP odaklı

Temel kavramlar:

• Raft consensus — distributed transaction commit'in çoğunluk replikası tarafından onaylanması
• Distributed SQL — JOIN'i, transaction'ı dağıtık olarak çalıştırma
• Horizontal scale + ACID — node ekleyerek büyüme + tutarlılık koruma
• Geo-distributed — birden çok bölge (region) arası replikasyon, follower read
• Multi-region active-active — write conflict çözümü, vector clock veya hybrid logical clock

Ne zaman seçilir:

• Geo-distributed e-commerce / SaaS, küresel müşteri
• Hem ACID hem petabyte scale (klasik tradeoff'tan kaçma)
• Postgres / MySQL uyumlu API ile drop-in replacement (TiDB / YugabyteDB)

Ne zaman seçilmez:

• Tek bölge, orta ölçek (klasik PostgreSQL yeterli ve daha basit)
• Operasyonel ekip / sysadmin deneyimi yetersiz (Raft, distributed debugging zor)

10 Boyutlu Karşılaştırma Matrisi

Aileler arası farkı tek tabloda özetlemek:

Boyut	SQL (RDBMS)	Document	Key-Value	Wide-Column	Graph	Time-Series	Search	Vector	NewSQL
Veri modeli	Tablo	JSON doc	K→V	Geniş satır	Düğüm + ilişki	Zaman serisi	Inverted index	Embedding vektör	Tablo (dağıtık)
Şema	Sıkı (write)	Esnek (read)	Yok	Esnek	Yarı-esnek	Tag/label	Mapping	Vector(N)	Sıkı (write)
Sorgu dili	SQL	MQL, Mango, vendor	API komut	CQL	Cypher, Gremlin	InfluxQL/Flux, PromQL, SQL	Query DSL	k-NN API + SQL	SQL
ACID	Tam	MongoDB 4.0+ multi-doc; çoğu kısıtlı	Çoğu yok (Redis Lua atomic var)	Kısıtlı	Neo4j tam, JanusGraph kısıtlı	Kısıtlı	Yok	DB'ye bağlı	Tam (dağıtık)
JOIN	Native	Sınırlı ($lookup)	Yok	Yok	Native (graph traversal)	Sınırlı	Yok	Hibrit sorgu	Native (dağıtık)
Tutarlılık	Strong (C)	Tunable	Çoğu eventual	Tunable	Strong	Eventual	Eventual	DB'ye bağlı	Strong (dağıtık)
Scale stratejisi	Genelde dikey + replica + partitioning	Yatay (sharding)	Yatay (cluster)	Yatay (ring)	Genelde dikey	Yatay (retention bazlı)	Yatay (cluster)	Yatay	Yatay (ACID)
Replikasyon modeli	Master-slave / sync / async	Replica set / sharded cluster	Master-replica / cluster	Masterless ring	Cluster	Cluster	Cluster	Cluster	Multi-region Raft
Use case tipik	OLTP, ERP, finans	CMS, katalog, event	Cache, session, queue	IoT, küresel write	Sosyal ağ, fraud	Metric, IoT sensor	Search, log	RAG, semantic	Geo-distributed SaaS
Operasyonel kompleksite	Düşük-orta	Orta	Düşük	Yüksek	Orta	Düşük-orta	Yüksek	Düşük-orta	Yüksek

Karar Matrisi: 10+ Pratik Senaryo

Mimaride en sık karşılaşılan iş alanlarını, hangi veritabanı veya kombinasyonun çözdüğünü gösterelim.

Senaryo 1: E-Ticaret Platformu (Türkiye, Orta Ölçek)

Bir Türkiye merkezli e-ticaret platformu — ürün katalog, sipariş, ödeme, müşteri, sepet.

Önerilen mimari:

• PostgreSQL — ana iş alanı: ürünler, kategoriler, siparişler, müşteriler, ödemeler, faturalar. ACID şart, JOIN yoğun. JSONB ile esnek ürün özellikleri (tipik kategoride değişen alanlar).
• Redis — session, sepet, rate limit, popüler ürün cache, leaderboard ("en çok satanlar")
• Elasticsearch / OpenSearch — ürün arama, filter, facet, otokomplet
• InfluxDB / TimescaleDB — server monitoring metrikleri (opsiyonel, alternatif: cPanel built-in)

Buyukweb bağlamı: WooCommerce, OpenCart, PrestaShop gibi paylaşımlı hosting üzerinde MySQL/MariaDB ile çalışan platformlar için cPanel paketlerimiz yeterli. Custom Postgres + Redis + Elasticsearch stack'i için VDS gerekir.

Senaryo 2: WordPress Blog veya Kurumsal CMS

WordPress 5.x, Drupal 10, Joomla 5 gibi geleneksel CMS.

Önerilen mimari:

• MySQL / MariaDB — WordPress'in doğal motor seçimi. wp_posts, wp_postmeta, wp_users, wp_options tabloları
• Redis (opsiyonel) — Object Cache eklentisiyle wp_options autoload + transient cache; trafiği 10x hızlandırır
• Elasticsearch (opsiyonel) — site içi arama (büyük blog/haber sitesi için)

Buyukweb bağlamı: cPanel hosting paketlerimiz WordPress için optimize; MariaDB 10.5 dahil.

Senaryo 3: Realtime Chat Uygulaması

Slack benzeri ekip mesajlaşması.

Önerilen mimari:

• PostgreSQL — kullanıcı, kanal, mesaj metadata, üyelik
• MongoDB veya Redis Streams — mesaj akışı (chronological, time-based query)
• Redis — presence ("kim online"), typing indicator, unread counter
• Elasticsearch — mesaj arama (full-text)

Senaryo 4: Sosyal Ağ İlişki Grafiği

Linkedin-vari profesyonel ağ, instagram-vari görsel ağ.

Önerilen mimari:

• PostgreSQL — kullanıcı profil, ana bilgi
• Neo4j veya JanusGraph — arkadaş / takipçi / mention / like ilişkileri, "arkadaşının arkadaşı" tipi 2-3 derece traversal
• MongoDB — gönderiler (post, story), her tipte farklı şema
• Redis — feed cache, presence
• Elasticsearch — hashtag, kullanıcı, içerik araması

Senaryo 5: Log Aggregation Platformu

Mikroservisler için merkezi log toplama.

Önerilen mimari:

• Elasticsearch + Kibana + Logstash/Fluentd (ELK/EFK stack) veya Loki + Grafana
• InfluxDB — uygulama metrikleri (request rate, error rate, latency)
• PostgreSQL — kullanıcı/proje metadata, alert konfigürasyonu

Buyukweb bağlamı: Bu stack VDS üzerinde self-host; 8-16 GB RAM minimum öneririz.

Senaryo 6: IoT Sensör Verisi

Akıllı bina / fabrika sensör verisi.

Önerilen mimari:

• InfluxDB veya TimescaleDB — sensör time-series (sıcaklık, nem, basınç, vibration)
• PostgreSQL — cihaz envanteri, kullanıcı, yapılandırma, alarm rule
• MQTT broker (örn. Mosquitto, EMQX) — cihazlardan veri toplama; ardından TSDB'ye yazma
• Grafana — görselleştirme dashboard

Senaryo 7: Session Store / Cache Layer

Mevcut bir RDBMS uygulamasını ölçeklendirme.

Önerilen mimari:

• Redis — primary session store, kullanıcı oturum verisi, JWT blacklist
• Redis — RDBMS sorgu sonuçlarını cache (query cache pattern)
• Redis — rate limit, throttling, captcha rate

Senaryo 8: Cart + Catalog Hibrit (E-Ticaret İç Sistem)

Sepet hızlı, katalog ilişkisel.

Önerilen mimari:

• PostgreSQL — ürün katalog, kategori, fiyat, stok (kalıcı, tutarlı)
• Redis — kullanıcı sepeti (geçici, TTL ile expire); kullanıcı checkout'a basınca PostgreSQL transaction'a aktarılır
• Elasticsearch — ürün arama

Senaryo 9: Geo-Distributed E-Ticaret (Küresel)

Tek değil çoklu bölge satış (TR + EU + US).

Önerilen mimari:

• CockroachDB veya TiDB — küresel ACID, geo-replication, çoklu bölge active-active
• Redis Cluster — global cache (bölgesel replika)
• Elasticsearch — bölgesel arama indeksi
• Object storage (S3-uyumlu) — görsel, statik dosya

Buyukweb bağlamı: Şu anda tek bölge (Bursa Tier 3). Geo-distributed senaryo birden çok sağlayıcının + birden çok bölgenin kombinasyonunu gerektirir.

Senaryo 10: AI Chatbot / RAG Backend

Şirket içi knowledge base üzerine LLM destekli chatbot.

Önerilen mimari:

• PostgreSQL + pgvector extension — kullanıcı, konuşma geçmişi, embedding tablosu hepsi tek DB'de
• Redis — kısa süreli conversation context cache
• Elasticsearch (opsiyonel) — hibrit search (vector + keyword)
• Object storage — kaynak doküman saklama (PDF, TXT)

Buyukweb bağlamı: PostgreSQL + pgvector self-host VDS'te kurulur. LLM inference ayrı bir hizmettir (Buyukweb LLM hosting vermez).

Senaryo 11: Mobil Uygulama Backend (Startup, MVP)

Yeni başlayan bir mobil uygulama, hızlı iterasyon.

Önerilen mimari (KISS):

• PostgreSQL — single DB, JSONB ile esnek alanlar
• Redis — session, cache
• (Elasticsearch sonra eklenir, ihtiyaç oluşunca)

Anti-pattern: "Belki gerekir" diye 5 farklı DB ile başlamak. KISS, sonra ihtiyaç oluşunca ekle.

Polyglot Persistence: Her Servis Kendi DB'sini Seçer

Polyglot persistence terimi 2011'de Martin Fowler tarafından popülerleştirildi. Temel ilke: monolitik tek-DB mimarisinden, her bounded context'in kendi DB ailesini seçtiği mimariye geçiş.

Polyglot persistence avantajları:

• Her veri türü en uygun motorla saklanır (performans, modelleme)
• Her servis kendi DB'sini bağımsız scale eder
• Bir servisin DB sorunu diğerini etkilemez (izole failure)

Polyglot persistence dezavantajları:

• Operasyonel karmaşıklık çoğalır (5 farklı DB, 5 farklı backup, 5 farklı monitoring)
• Cross-DB transaction zor (eventual consistency, saga pattern)
• Ekip aynı anda 5 farklı DB tipi öğrenmek zorunda

Pratik kural: Küçük başla, ihtiyaç oluşunca böl. Bir MVP için PostgreSQL + Redis (2 DB) yeterlidir. Trafik büyüdükçe Elasticsearch eklenir, log için InfluxDB eklenir.

PostgreSQL: İsviçre Çakısı Yaklaşımı

NoSQL ailelerinin çoğunu PostgreSQL extension ile aynı veritabanında alabilirsiniz:

• Relational — varsayılan
• Document (JSON) — jsonb tipi, GIN index, jsonb_path_query, @> containment
• Key-Value — hstore extension (basit), JSONB de kullanılabilir
• Full-text search — tsvector, tsquery, GIN index ile yerleşik
• Geospatial — PostGIS extension (sektörde dominant GIS motoru)
• Time-Series — TimescaleDB extension; hypertable + chunk
• Vector — pgvector extension; HNSW / IVFFlat index
• Horizontal scale — Citus extension; distributed table + sharding
• Graph (basic) — recursive CTE ile temel graph traversal; ileri seviye için ayrı graph DB

Sonuç: Küçük-orta ölçekli projelerde PostgreSQL tek başına Document + Key-Value + Search + Time-Series + Vector ihtiyaçlarını çözebilir. Polyglot persistence'a geçiş, gerçekten ihtiyaç oluşunca yapılır.

SQL → NoSQL ve NoSQL → SQL Migration

Veritabanı taşıma nadir ama gerçektir.

SQL → NoSQL (Örnek: MySQL → MongoDB)

1. Veri modelini yeniden tasarla — normalize edilmiş tablolardan denormalize edilmiş dokümanlara. JOIN'lar embed veya referans ile gider.
2. Migration script — Python/Node.js ile MySQL'den okuyup MongoDB'ye yazma. Batch size 1000-10000, paralel worker.
3. Dual-write fazı — uygulama hem MySQL'e hem MongoDB'ye yazar; eski read'ler MySQL'den, yeni read'ler MongoDB'den
4. Cutover — tüm okuma trafiğini MongoDB'ye yönlendir, MySQL bakım moduna
5. Decommission — MySQL kapat

NoSQL → SQL (Örnek: MongoDB → PostgreSQL)

1. Şemayı normalize et — embedded array'leri ayrı tabloya, referans'ları FK'a
2. Schema evolution — production'da çeşitli doc varyasyonları olduğu için, hepsini kapsayan birleşik şemayı çıkarmak gerekir
3. Migration script — MongoDB'den okuyup PostgreSQL'e yazma; doc varyasyonu tespit edip normalize
4. Dual-write fazı + cutover — yukarıdakinin tersi
5. Decommission

Süre tahmini: 100 GB veri için 2-4 hafta tam takım; 1 TB için 2-3 ay.

NoSQL Hakkında 10 Yaygın Yanlış

1. "MongoDB hızlıdır, MySQL yavaştır"

Yanlış. MongoDB primary key lookup'ta MySQL kadar hızlıdır; aggregation veya JOIN-benzeri sorguda MySQL daha hızlı olabilir. Hız iş yüküne bağlıdır.

2. "NoSQL ACID yok"

Eski. MongoDB 4.0+ multi-document transaction desteği var. Neo4j ACID tam. CockroachDB / TiDB dağıtık ACID. ACID artık SQL'in tekeli değil.

3. "NoSQL schema yok"

Yanlış. Schema-on-read var. Yani veritabanı zorlamaz ama uygulama ya da schema validation framework (MongoDB JSON Schema, Mongoose, Zod) zorlar. Hiçbir prodüksiyon sistemi gerçekten "şemasız" değildir.

4. "SQL yatay scale etmez"

Yanlış. Read replica standart; partitioning / sharding her motorda var; Citus PostgreSQL'i yatay scale eder; Galera Cluster MariaDB için multi-master HA. CockroachDB / TiDB dağıtık ACID SQL.

5. "JOIN için 5 collection birden sorgulamak normal"

Yanlış. MongoDB'de JOIN benzeri $lookup var ama 5'li JOIN için kullanmak işaret: veri modeli yanlış. Doğru NoSQL tasarımı denormalize edilmiş doc kullanır.

6. "MongoDB web ölçeği için"

2010'da viral olan ironik bir cümle. MongoDB hâlâ yer alır ama her use case için doğru tercih değil. Belirli use case (CMS, katalog, event store, profil yönetimi) için iyidir.

7. "Redis sadece cache için"

Eksik. Redis primary store olarak kullanılabilir; RDB + AOF persistence yeterli güvenlik sağlar. Çoğu rate limiter, session store, leaderboard, kuyruk için primary.

8. "Cassandra her şey için süper"

Yanlış. Cassandra belirli use case için süper (yüksek write, AP, küresel coğrafi dağıtık). 100 GB veri ve 100 RPS yük için Cassandra abartı. PostgreSQL daha basit ve hızlı olur.

9. "Vector DB yeni teknoloji, ayrı kurmalıyım"

Yanlış (genelde). pgvector PostgreSQL extension'ı RAG senaryolarının çoğunu çözer. Ayrı vector DB kurmak operasyonel yük ekler. Sadece çok büyük scale'de (10M+ vektör) ayrı vector DB değerli.

10. "Polyglot persistence en doğru mimari"

Yarım gerçek. Polyglot bazı senaryolarda doğru ama operasyonel ekibinize göre karar verin. Tek sysadmin'iniz var ve 5 farklı DB'yi izleyemiyorsanız, PostgreSQL + Redis combo daha verimli.

Buyukweb VDS Bağlamı: Hangi DB'yi Nereye Kuruyorsunuz?

cPanel Paketlerinde Doğal Çalışan DB'ler

cPanel hosting paketlerimiz (Başlangıç, Performans, Uçak, Jet):

• MariaDB 10.5 — standart, dahil. WordPress, OpenCart, PrestaShop, Joomla, Drupal, Laravel/Symfony ile sorunsuz çalışır.
• PostgreSQL — cPanel paylaşımlı paketlerde standart gelmez. PostgreSQL ihtiyacınız varsa VDS önerilir.
• MongoDB / Redis / Cassandra / Neo4j / Elasticsearch — paylaşımlı paketlerde yok; VDS gerektirir.

VDS Sunucularda İstediğiniz DB

VDS sunucularımızda (E5-V4, NVMe SSD) root erişimle istediğiniz veritabanını kurarsınız:

• PostgreSQL — apt install postgresql-15 / dnf install postgresql15-server veya PGDG depo
• MongoDB — resmi MongoDB repo, mongodb-org paketi
• Redis — apt install redis-server / paketten veya kaynaktan
• Apache Cassandra — DataStax repo veya Apache resmi
• Elasticsearch / OpenSearch — Elastic/OpenSearch resmi depo
• InfluxDB / TimescaleDB — InfluxData resmi / TimescaleDB Postgres extension olarak
• Neo4j — Neo4j Community veya Docker
• pgvector — PostgreSQL extension, CREATE EXTENSION vector;

VDS Boyutlandırma Önerisi

Veritabanı tipine göre minimum kaynak önerimiz:

DB	Min RAM	Min Disk	Min CPU	Tipik Buyukweb VDS Paketi
PostgreSQL (orta yük)	4 GB	50 GB SSD	2 vCPU	E5-V4 4GB / 6GB
MongoDB (replica set, tek node)	4 GB	100 GB SSD	2 vCPU	E5-V4 6GB
Redis (cache primary)	2-8 GB	20 GB SSD	1-2 vCPU	E5-V4 4GB
Cassandra (tek node)	8 GB	200 GB SSD	4 vCPU	E5-V4 8GB+
Elasticsearch (tek node)	8 GB	100 GB SSD	2-4 vCPU	E5-V4 8GB+
InfluxDB (orta yük)	4 GB	200 GB SSD	2 vCPU	E5-V4 6GB
Neo4j Community (tek node)	4 GB	50 GB SSD	2 vCPU	E5-V4 6GB
pgvector (Postgres içinde)	6-8 GB	50 GB SSD	2-4 vCPU	E5-V4 8GB
TimescaleDB (Postgres içinde)	4-8 GB	200 GB SSD	2-4 vCPU	E5-V4 8GB

Cluster kurulumu (replica set, sharded cluster, multi-node Cassandra) için 3-5 ayrı VDS önerilir. Fiyatlar: VDS paketleri ₺250-600/ay arasında başlar; güncel için VDS sunucu sayfamıza bakınız.

Buyukweb Yönetilen NoSQL Hizmeti Var Mı?

Yok. Buyukweb bir hosting şirketidir; yönetilen veritabanı SaaS hizmeti vermiyoruz. cPanel'deki MariaDB hariç (zaten cPanel paketinin doğal parçası), VDS'te kurulan DB'lerin yönetimi sizdedir. Bu, TCO ve esneklik avantajıdır:

• Tam kontrol — config, sürüm, replica sayısı, backup stratejisi sizin
• Vendor lock-in yok — istediğiniz zaman başka sağlayıcıya taşırsınız
• Fiyat öngörülebilir — VDS sabit ücret; "request başına" sürpriz fatura yok

Dezavantaj: Sysadmin bakımı sizin tarafınızda — kurulum, güncelleme, yedek, monitoring, sertifika, replication, partitioning.

Sık Sorulan Sorular (SSS)

WordPress için NoSQL kullanmalı mıyım?

Hayır. WordPress core MySQL/MariaDB üzerinde çalışır; başka DB kurulamaz. Redis Object Cache eklentisiyle Redis'i cache layer olarak ekleyebilirsiniz (10x hız kazancı tipiktir) ama primary DB her zaman MariaDB.

PostgreSQL mi MongoDB mi öğrenmeliyim?

Yeni başlıyorsanız önce SQL öğrenin (PostgreSQL veya MySQL). SQL, son 50 yılın temel becerisi; MongoDB bir spesifik aile. SQL'i sağlam öğrendikten sonra MongoDB öğrenmek 1-2 haftalık iş. Ters yönde başlamak, ileride SQL'i geç fark etmenize neden olur.

Hangi NoSQL motoru en kolay öğrenilir?

Redis, key-value modelinin sadeliği nedeniyle en hızlı öğrenilen NoSQL. MongoDB ikinci, document modeli JSON aşina geliştiriciler için sezgisel. Cassandra ve Neo4j daha uzun bir öğrenme eğrisi gerektirir.

Cassandra ne zaman gerekli?

Şu kontrollerin çoğunluğu evet ise:

• 100 GB+ ölçek, yıllık 10x büyüme bekliyorsunuz
• Saniyede 10.000+ yazma (tek master DB'ye sığmaz)
• Küresel coğrafi dağıtık yazma (multi-region active)
• AP tarafı tercih ediyorsunuz (tutarsız okumayı kabul ediyorsunuz)
• 3+ node cluster işletecek sysadmin ekibiniz var

Aksi halde PostgreSQL (Citus extension ile) veya TimescaleDB (time-series özel) daha pratik.

Redis primary DB olabilir mi?

Belirli use case için evet, genel amaçlı veritabanı olarak hayır. RDB + AOF persistence ile veri kaybı riski düşük, ama Redis Cluster operasyonel kompleksite ekler. Primary olabileceği case'ler: session store, queue, cache, leaderboard, rate limiter, real-time presence. Primary OLMAMASI gereken case'ler: kalıcı kullanıcı/müşteri/sipariş verisi (Postgres/MySQL daha doğru).

Buyukweb yönetilen NoSQL bulut servisi sunuyor mu?

Hayır. Buyukweb bir hosting şirketidir; yönetilen NoSQL SaaS hizmeti vermez. Müşterilerimize cPanel paketinde MariaDB veya VDS üzerinde self-host öneriyoruz; bu yaklaşımın avantajı: KVKK uyumlu TR datacenter (Bursa Tier 3), vendor lock-in yok, fiyat öngörülebilir (request başına sürpriz fatura yok). Yönetim sorumluluğu (kurulum, güncelleme, backup, monitoring) sizdedir; bu hem kontrol hem operasyonel yük demektir.

NewSQL klasik SQL'in yerini alacak mı?

Yakın gelecekte hayır. NewSQL çok büyük scale + ACID + dağıtık istisna durumlar için. Klasik PostgreSQL / MySQL küçük-orta ölçekte daha basit, daha hızlı, daha öğrenilmiş. NewSQL geç optimizasyon, erken değil.

Schema-on-read ne demek, schema yok mu?

Schema-on-read = veritabanı yazımda şemayı zorlamaz, ancak uygulama veya schema validation framework okumada/yazmada şemayı doğrular. Yani şema var, sadece veritabanı motorunda değil uygulamada. "Şemasız" iddiası yanlış, sadece "esnek şema".

Sonuç ve Sonraki Adımlar

Veritabanı seçimi 2026'da artık "SQL vs NoSQL ikili karar" değil; dokuz aile arasında çok boyutlu bir uyum problemi. Pratik kurallar:

1. Başlangıçta sade — MVP için PostgreSQL veya MySQL + Redis (cache) yeterli. Ekstra DB ihtiyaç oluşunca eklenir.
2. PostgreSQL'in genişliği unutulmasın — JSONB (document), pgvector (vector), TimescaleDB (time-series), PostGIS (geo), Citus (yatay scale) ile çok rol oynar.
3. Doğru DB'yi doğru role koyun — Redis primary OLTP DB olmaz; PostgreSQL real-time chat presence için ideal değil.
4. CAP ve PACELC trade-off'unu bilin — AP mi CP mi seçiyorsunuz, normal koşulda L mi C mi tercih ediyorsunuz?
5. Schema-on-write disiplini değerli — esneklik için NoSQL seçerken, validation framework ile schema disipline edin.
6. Operasyonel ekip kapasitesini gözetin — 5 farklı DB öğrenmek + bakım yapmak küçük ekipler için reel maliyet.
7. Polyglot persistence ihtiyaçtan doğsun — peşinen 5 DB ile başlamak anti-pattern; ihtiyaç oluşunca böl.

Buyukweb cPanel paketlerimizde MariaDB 10.5 standart sunuyoruz; PostgreSQL, MongoDB, Redis, Cassandra, Elasticsearch, InfluxDB, Neo4j ve benzeri motorlar için VDS sunucularımızda root erişimle istediğiniz kombinasyonu kurarsınız. Bursa Tier 3 veri merkezi, KVKK uyumlu TR datacenter avantajı sağlar.

---

İlgili Büyükweb Hizmetleri

• cPanel Web Hosting — MariaDB 10.5 dahil, WordPress/PHP uygulamaları için
• VDS Sunucu — PostgreSQL, MongoDB, Redis, Cassandra, Elasticsearch self-host platformu
• E5-V4 VDS — yüksek IOPS, NVMe SSD, veri yoğun iş yükleri için
• Fiziksel Dedicated — büyük veri ya da çoklu node cluster için
• Paket Karşılaştırma — disk / RAM / CPU ihtiyacınıza göre paket seçimi
• WordPress Hosting (MariaDB) — MariaDB-tabanlı CMS için optimize paket

Veritabanı seçimi, polyglot persistence mimari kararı veya VDS üzerinde özel NoSQL stack kurulumu için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz. Bursa Tier 3 veri merkezimizde KVKK uyumlu TR datacenter avantajıyla sunuyoruz.