Non-relational store seçimi, çözümlenmiş
"NoSQL kullanmalı mıyız?" 10 yıl önceki soruydu. 2026'da dürüst cevap: muhtemelen primary olarak değil, sıkça secondary olarak. Modern Postgres bir zamanlar "NoSQL bölgesi" olanın çoğunu ele alır.MongoDB
Ne için: derin nesting'li document-şekilli veri, erken ürün geliştirmesinde şema esnekliği, document-by-id okumaların hakim olduğu uygulamalar.Şu durumlarda: uygulamanın verisi gerçekten document-şekilli, "doc'lara çakacağız" değil.
DynamoDB
Ne için: AWS-native key-value, herhangi bir ölçekte öngörülebilir tek haneli-ms gecikme.Şu durumlarda: AWS-yerleşik, ölçek önemli, erişim desenleri önceden bilinebilir.
Cassandra / ScyllaDB
Ne için: write-ağır, scale-out, sonunda-tutarlı iş yükleri. Devasa ölçekte time-series, IoT / telemetry ingest.Şu durumlarda: write throughput bağlayıcı kısıt, veri net bir anahtarla doğal olarak bölünebilir.
Elasticsearch / OpenSearch
Ne için: tam metin arama, log analitik, fuzzy / relevance ranking ile "belge" arama gereken her şey.Şu durumlarda: tam metin veya analitik tarzı arama uygulamanın anlamlı parçası.
Redis
Ne için: cache, kuyruk, leaderboard, rate limiter, geçici state.Şu durumlarda: cache, kuyruk veya hızlı erişim geçici state'e ihtiyacınız var.
PostgreSQL sorusu
Modern Postgres birçok "NoSQL" seçimini değiştirebilir:- Document-şekli veri için JSONB kolonları.
- Tam metin arama (ts_vector / pg_trgm).
- Time-series için TimescaleDB.
- Geospatial için PostGIS.
- Vector embedding'leri için pgvector.
2026'da çoğu proje için "Postgres + Redis" tarihsel olarak çok-database NoSQL bölgesi olanın %80'ini ele alır.
Karar çerçevesi
- Varsayılan: Postgres + Redis.
- Ağır arama: + Elasticsearch.
- Document-şekli, şema esnekliği kritik: MongoDB.
- AWS-native ölçek + öngörülebilir erişim: DynamoDB.
- Devasa write throughput: Cassandra / ScyllaDB veya TimescaleDB.
- Vector embedding'ler: pgvector veya adanmış vector DB.
Hayatta kalan veri katmanı
- Entity başına tek source of truth.
- Store'lar arası veri taşımak için CDC (Debezium, ECS).
- Read-heavy secondary store'lar için async replikasyon.
- Her store için yedek ve DR.
- "Schemaless" store'larda bile şema evrim disiplini.
Uyaracağımız bir desen
Varsayılan olarak polyglot persistence.Her zaman karşılığını veren bir desen
NoSQL store seçmeden önce erişim desenlerini modellemek.Veri katmanınız nedir?
Picking a non-relational store, untangled
"Should we use NoSQL?" was the question 10 years ago. The honest answer in 2026: probably not as your primary, often as your secondary.MongoDB
What it's for: document-shaped data with deep nesting, schema flexibility during early product development.Use when: the application's data really is document-shaped.
DynamoDB
What it's for: AWS-native key-value with predictable single-digit-ms latency at any scale.Use when: AWS-resident, scale matters, access patterns are knowable in advance.
Cassandra / ScyllaDB
What it's for: write-heavy, scale-out, eventually-consistent workloads.Use when: write throughput is the binding constraint.
Elasticsearch / OpenSearch
What it's for: full-text search, log analytics.Use when: full-text or analytics-style search is meaningful.
Redis
What it's for: cache, queue, leaderboard, rate limiter.Use when: you need a cache, queue, or fast-access ephemeral state.
The PostgreSQL question
Modern Postgres can replace many "NoSQL" choices:- JSONB columns for document-shape data.
- Full-text search (ts_vector / pg_trgm).
- TimescaleDB for time-series.
- PostGIS for geospatial.
- pgvector for vector embeddings.
The decision framework
- Default: Postgres + Redis.
- Heavy search: + Elasticsearch.
- Document-shaped: MongoDB.
- AWS-native scale: DynamoDB.
- Massive write throughput: Cassandra / ScyllaDB.
- Vector embeddings: pgvector.
The data layer that survives
- One source of truth per entity.
- CDC to move data between stores (Debezium).
- Async replication.
- Backup and DR for every store.
- Schema evolution discipline.
One pattern we'd warn about
Polyglot persistence as a default.One pattern that always pays off
Modelling access patterns before picking a NoSQL store.What's your data layer?
