Veritabanı türleri - SQL, NoSQL ve ben hangisini ne zaman gerçekten seçerim

«Veritabanı türü» bir marka değildir. PostgreSQL ve MySQL ikisi de ilişkiseldir. MongoDB ve Firestore ikisi de belge deposudur. Redis, ekiplerin önbellek, kuyruk ve bazen tehlikeli bir birincil depo olarak kullandığı bir anahtar-değer motorudur. Bir rehber kullandı diye veritabanı seçmek moda seçmektir. Verinin şekline ve uygulamanın nasıl sorguladığına göre seçmek mimaridir.

Biri «SQL mi NoSQL mu?» diye sorduğunda kullandığım harita budur - genelde yanlış ilk sorudur. İlk soru: bu üründe bir satır (veya belge, veya düğüm) nedir, ne tutarlı kalmalı, ve uygulama günde bin kez hangi soruları soracak?

1. «Tür» gerçekte ne demek

Üç eksen, pazarlama kategorisinden daha önemlidir. Bunları yanlış seçerseniz kutunun üzerindeki logo sizi kurtarmaz.

• Veri modeli: ilişkili tablolar, iç içe belgeler, anahtarlar, graflar, zaman kovaları veya vektörler.
• Sorgu modeli: join, alana göre filtre, get-by-key, graf dolaşımı, zaman aralığı veya «bu embedding’e ne yakın?»
• Garantiler: ACID işlemler, eventual consistency, tek düğüm sadeği - gece 2’de uğraşacağınız bir kümeye karşı.

2. İlişkisel (SQL) - para ve ilişkiler için varsayılan

PostgreSQL, MySQL, SQLite. Tablolarda satırlar, yabancı anahtarlar, join’ler, migration’lar, ACID işlemler. Çoğu web ürünü için hâlâ doğru ev: kullanıcılar, çalışma alanları, roller, siparişler, faturalar, rezervasyonlar, stok. Bir satır başka bir satır var diye var olmalıysa, veya bir çekim iki kez olmamalıysa, ilişkisel bir motor istersiniz - JSON blob ve bir dua değil.

PostgreSQL 2026’daki varsayılanım: alan gerçekten şemasızsa JSONB, küçük arama için yerleşik full-text, RAG sonra gelirse pgvector. İkinci bir veritabanına «ihtiyaç» duymadan uzun süre büyüyebilirsiniz. SQLite, local-first, CLI ve minik ürünler için hak ettiğinden az kullanılır. MySQL, ekip zaten onu işletiyorsa iyidir - sıfırdan orada başlamam.

• Görev bütünlük, join’li rapor ve «bu çalışma alanında kim ne için ödedi» ise SQL seçin.
• SQL’i «enterprise» diye seçmeyin. Alan, birlikte doğru kalması gereken olgular grafı olduğu için seçin.

3. Belge veritabanları - esnek nesneler, pahalı ilişkiler

MongoDB, CouchDB, Firestore, belge kipinde DynamoDB. Belge bir JSON ağacıdır. İş birimi her zaman birlikte yüklenen iç içe parçaları olan tek bir nesneyse uyar: bir CMS yazısı, dağınık öznitelik torbası olan bir ürün, her zaman bütün çektiğiniz bir kullanıcı profili.

Tuzak: hâlâ kullanıcılar, çalışma alanları ve faturalar vardır. Join’leri uygulamada yeniden icat eder, çok belgeli işlemleri kaybeder (veya ödersiniz) ve ilişkisel motorun ilk günde vereceği teklik kurallarını bir yıl eklersiniz. Ürün içerik şeklindeyse ve erişim kalıbı «bu blob’u id ile yükle» ise belge deposu kullanırım. Frontend JSON konuşuyor diye değil. Postgres JSONB zaten JSON konuşur.

4. Anahtar-değer - Redis ve dostları

Saf anahtar-değer olarak Redis, Memcached, DynamoDB. Get, set, expire. İsteğe bağlı listeler, kümeler, pub/sub. İşin kaydı burada yaşamaz. Yanındaki hızlı katmandır.

• İyi: oturumlar, rate limit, özellik anahtarları, idempotency anahtarları, pahalı okuma önbelleği, kısa kilitler.
• Kötü: sipariş, kullanıcı veya izinlerin tek kopyası. Bir flush veya eviction politikası - ve destek kabusu.

5. Wide-column - yazmalar hiç durmadığında

Cassandra, Scylla, Bigtable. Bir anahtarla partition eder, çok yazar, o anahtarla okur ve ad-hoc SQL’in mesele olmadığını kabul edersiniz. Devasa ölçekte telemetri, gelen kutusu tarzı akış, çok bölgeli yazma ağır iş yükü için doğru. On iki tabloluk bir rezervasyon SaaS’ı için yanlış. «Saniyede milyonlarca yazma» gibi bir sayınız yoksa bu kategoriyi atlayın. Kümenin işletme maliyeti üründür.

6. Graf - soru bağlantının kendisiyken

Neo4j, Amazon Neptune ve - küçük graflar için - özyinelemeli CTE’li SQL. Ürün ağın kendisiyse graf motoru kullanın: öneriler, dolandırıcılık halkaları, org şemaları, izin kalıtımı, «bu tedarikçiden iki adım kim». Beyaz tahtaya kutu ve ok çizdiniz diye değil. Neredeyse her alanın ilişkisi vardır. İlişkisel veritabanları ilişkileri zaten modeller. Graf motorları, dolaşım derinliği şema diyagramı değil sorgu olduğunda yerini hak eder.

7. Time-series - metrikler, sensörler, zaman içindeki olaylar

InfluxDB, TimescaleDB, ops için Prometheus, analitik şekilli olaylar için ClickHouse. Her satır «bu cihaz veya metrik, bu timestamp’te» ise genel bir OLTP şeması acıtır: çok insert, range tarama, saklama politikaları. TimescaleDB çekicidir çünkü PostgreSQL kalır - aynı yedekler, aynı SQL, sıcak yol için hypertables. ClickHouse analitiktir, kasa işlemi değil. created_at diye bir kolon var diye sipariş tablosunu time-series motora dökmeyin.

8. Vektör - embedding’ler, ikinci bir asıl kayıt değil

Pinecone, Qdrant, Weaviate ve Postgres içindeki pgvector. Vektör saklarsınız ki «bu soruya hangi metin yakın?» diye sorun. Bu RAG, anlamsal arama, kopya tespiti. Yazı, fiyat, kullanıcı hâlâ operasyonel veritabanında yaşar. Vektör indeksi, arama gibi türetilmiş bir indekstir. Yeniden kurulur. Kasa veya izinlerin ona bağlı olmasına izin vermeyin.

2026’da önce Postgres’e pgvector eklerim. Corpus boyutu ve QPS başka bir hareketli parçayı haklı kıldığında ayrı bir vektör veritabanı - bir yatırımcı sunumu «AI-native» dediği için değil.

9. Arama, kayıt veritabanı değildir

Elasticsearch, OpenSearch, Typesense, Meilisearch. Full-text, yazım hatası toleransı, facet, ranking. Asıl kayıttan yeniden kurun. Kasa, stok veya izinlerin, başarısız bir reindex sonrası sapabilecek bir indekse bağlı olmasına asla izin vermeyin. Postgres full-text birçok küçük katalog için yeter. Kullanıcılar dağınık sorgular yazıp relevans gerektiğinde arama motoru ekleyin - SQL’den sıkıldığınız için değil.

10. Gerçekten nasıl seçerim

Filtreleri bu sırayla çalıştırırım. Stack, karşılaştırma tablosundan önce değil, yanıtlardan sonra gelir.

• Tutarlılığın birimi nedir? Para veya stok hareket ediyorsa, işlemli SQL. «Çiftleri uygulamada düzeltiriz» değil.
• Sıcak sorgu nedir? Id, join, full-text, benzerlik, zaman aralığı veya graf adımı? Motoru o şekle bağlayın.
• Bunu gece 2’de kim işletir? Ekipte kimsenin başa çıkamadığı zeki bir kümeden bir managed Postgres iyidir.
• Tek motor %80’i karşılar mı? Postgres artı Redis, gerçekten canlıya aldığım web ürünlerinin çoğunu karşılar.

Gerçekten başlayacağım bir 2026 varsayılanı

Veri modeli ilk günden uzman bir depo dayatmadıkça bu stack ile açardım - ve bir blog yazısı değil, ölçülmüş bir darboğaz belirene kadar genişletmeyi reddederdim.

• Asıl kayıt olarak PostgreSQL. Alan gerçekten şemasızsa JSONB. RAG slayt değil gerçek bir özellikse pgvector.
• Önbellek, oturum, rate limit ve hafif kuyruklar için Redis. Siparişler için değil.
• Dosyalar için nesne depolama. LIKE ve Postgres FTS yetmediğinde arama motoru.

Tür, görevin şeklidir

SQL’e karşı NoSQL, 2010’ların tartışmasıydı. 2026’daki işe yarar soru: hangi veri modeli göreve uyar, ve kaç sistemi iyi işletebilirsiniz - olabildiğince az. İlişkisel bir asıl kayıtla başlayın. Sorgu şekli gerçekten farklıysa uzman depo ekleyin - önbellek, arama, vektör, time-series. Hibrit normaldir. Bir MVP’nin ilk gününde beş veritabanı, deneyin ölme biçimidir.