ClickHouse 2025 Performance benchmark’larında 100 milyar satırlık analitik sorgular PostgreSQL’e kıyasla ortalama 100x, belirli aggregate’lerde 1.000x’e varan hızlandırma raporlanıyor. DuckDB 2025 Embedded Analytics raporunda ise tek-makine analitik için 12 GB veri seti üzerinde Spark cluster’ı yenip 1/8 maliyetle çalışıyor. Konuyla ilişkili olarak DuckDB ile Analytic Workloads: Embedded OLAP Yeni Çağ rehberimiz detaylı incelemeyi içerir.

OLAP 2026: Kolon Tabanlı Motorların Yükselişi

Online Analytical Processing (OLAP) motorları aggregat sorguları yüksek hızda işleyen kolon-tabanlı veri tabanları. Geleneksel satır-tabanlı OLTP (PostgreSQL, MySQL) milyon satırlık analitik sorgularda yetersiz kalırken kolon-tabanlı motorlar SIMD vektörize execution, kompres edilmiş kolon storage ve materialized view ile saniye altı yanıt veriyor. Forrester 2025 OLAP Database Wave değerlendirmesinde ClickHouse, DuckDB ve StarRocks üç hızlı yükselen “Strong Performer” oldu.

2026 pazar verisi: ClickHouse 1.500+ kurumsal müşteri (ClickHouse Inc 2025 yıllık verileri), DuckDB 3+ milyon download/ay (DuckDB Foundation), StarRocks 800+ aktif production deployment. ClickHouse Cloud son 12 ayda %124 büyüdü, DuckDB embedded analytics segmentinde Pandas alternatifi olarak konumlanıyor.

Mimari Karşılaştırma: Sharded, Embedded, MPP

Üç motor farklı mimari paradigmalar temsil ediyor. ClickHouse distributed table + shard + replica pattern’iyle horizontal ölçek; DuckDB tek-process embedded analytical engine, scale-up odaklı; StarRocks MPP (massively parallel processing) + cloud-native disaggregated storage. Her birinin sweet spot’u farklı use case.

Özellik ClickHouse DuckDB StarRocks
Mimari Shared-nothing distributed Embedded single-process MPP disaggregated
Veri boyutu 100GB-100PB 1GB-1TB 10GB-10PB
Concurrency Düşük-orta (50-200) Tek user Yüksek (500+)
Update/Delete Sınırlı Tam destek Primary key model
Federation Sınırlı Postgres, MySQL, Parquet Iceberg, Hive
OLAP Karşılaştırma 2026: ClickHouse, DuckDB ve StarRocks Production Analizi — Görsel 1
OLAP Karşılaştırma 2026: ClickHouse, DuckDB ve StarRocks Production Analizi — Görsel 1

TPC-H Benchmark: Gerçek Performans Verileri

ClickBench (clickhouse.com/benchmarks) 2025 sonuçlarına göre ClickHouse 100GB üzerinde 43 query toplam 32 saniye, StarRocks 41 saniye, DuckDB tek-makine 67 saniye sürüyor. PostgreSQL aynı workload için 1.247 saniye, BigQuery 89 saniye, Snowflake 78 saniye. Ancak bu rakamlar workload, hardware ve indexing’e bağlı; %25-40 değişkenlik var.

  • ClickHouse advantageous: yüksek-cardinality GROUP BY, time-series aggregate, count distinct
  • DuckDB advantageous: ad-hoc analitik, Parquet üzerinde query, notebook entegrasyonu
  • StarRocks advantageous: yüksek-concurrency BI workload, federated query
  • Tüm üçü PostgreSQL’e karşı analitik query’de 50-100x kazanıyor

Cloud DW karşılaştırmaları için Snowflake Databricks TCO analizimize bakabilirsiniz.

Concurrency Davranışı: 100 Eşzamanlı Kullanıcı Senaryosu

OLAP concurrency’si production’da kritik. 100 eşzamanlı dashboard kullanıcısı tipik enterprise BI senaryosu. ClickHouse default thread pool 200, üretim için 500-1000’e çıkarılabilir; p99 latency 500 concurrent’ta 2-5x artıyor. DuckDB embedded olduğu için multi-user senaryoda her process kendi DuckDB instance’ını çalıştırıyor, gerçek concurrency yok. StarRocks MPP mimarisi 1000+ concurrent query’yi p99 < 500ms ile çevirebiliyor. ClickHouse resmi blogunda concurrency tuning detayları yayımlanıyor.

OLAP Karşılaştırma 2026: ClickHouse, DuckDB ve StarRocks Production Analizi — Görsel 2
OLAP Karşılaştırma 2026: ClickHouse, DuckDB ve StarRocks Production Analizi — Görsel 2

Materialized View ve Incremental Refresh

OLAP sorgu hızlandırmanın en güçlü tekniği materialized view. ClickHouse materialized view insert sırasında inkremental hesaplıyor; StarRocks async refresh + smart matching; DuckDB sınırlı materialized view desteği var. Materialized view doğru kullanıldığında dashboard query’leri 100x hızlanıyor ama yanlış design’da maintenance maliyeti compute’u şişiriyor.

Özellik ClickHouse DuckDB StarRocks
MV strategy Insert-time inkremental Manual refresh Async + sync
Auto query rewrite Hayır, manuel Hayır Evet (smart match)
Maintenance overhead %15-25 insert Full rebuild %5-15 background
Use case Time-series aggregate Ad-hoc BI dashboard
Tipik hız kazanımı 20-100x 5-20x 50-200x

Sektörel Use Case Eşleştirmeleri

Ad-tech ve user-facing dashboard ClickHouse’un sweet spot’u; Cloudflare, eBay, Tinkoff Bank gibi büyük müşteriler petabayt ölçekli ClickHouse kullanıyor. Veri analisti self-service ve embedded analytics için DuckDB üstün; Hex, MotherDuck, Tableau gibi araçlar DuckDB ile entegre. Yüksek-concurrency BI workload (Tableau, Looker, Superset binlerce kullanıcı) için StarRocks öne çıkıyor; Airbnb, TRM Labs production’da kullanıyor.

OLAP Karşılaştırma 2026: ClickHouse, DuckDB ve StarRocks Production Analizi — Görsel 3
OLAP Karşılaştırma 2026: ClickHouse, DuckDB ve StarRocks Production Analizi — Görsel 3

Kurumsal OLAP Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

  • “Hepsi hızlı” diye benchmark’a bakmadan seçim yapılıyor; gerçek workload üzerinde POC atlanıyor
  • ClickHouse’a embedded use case için yöneliniyor; DuckDB daha uygun
  • StarRocks alınıyor ama Iceberg/Hive federation kurulmuyor, MPP avantajı kullanılmıyor
  • Materialized view tasarımı yanlış, maintenance maliyeti compute’u yiyor
  • Concurrency limit’i belirlenmiyor; 50 user’da p99 latency patlıyor
  • Replica/shard sayısı over-provision’ed; %40 kaynak israfı

Sonuç

OLAP 2026’da PostgreSQL ile analitik yapanları artık tutmuyor; 100x hızlandırma ve %60 maliyet düşüşü tek karar uzaklıkta. Doğru seçim use case profiline bağlı: yüksek-cardinality time-series + user-facing dashboard için ClickHouse, embedded + ad-hoc analitik için DuckDB, yüksek-concurrency BI workload için StarRocks. Karar öncesi mutlaka gerçek workload üzerinde 2 haftalık POC yapın; concurrency profili, materialized view rebuild süresi ve kompres oranı ölçün. Bu üç metrik olmadan seçim 6 ay sonra migrate edileceğiniz bir karara dönüşüyor.

Sıkça Sorulan Sorular

PostgreSQL’i analitik için tutmaya devam edebilir miyim?

10GB’ın altında veri ve günde 100’den az analitik sorgu varsa PostgreSQL yeterli. Üzerine çıkıldığında p99 latency 10+ saniyeye dayanıyor, kullanıcı deneyimi bozuluyor. PostgreSQL + cstore_fdw veya Citus extension’ı tarafından genişletilebilir ama native OLAP motorlar 50-100x daha hızlı.

DuckDB production’da kullanılabilir mi?

Embedded analytics ve API-driven analytical service için evet. Multi-user concurrent workload için hayır; DuckDB tek-process olduğu için her concurrent request kendi process’inde çalışmalı. MotherDuck (DuckDB Inc’in SaaS’ı) cloud edition multi-user destekliyor.

ClickHouse Cloud mu yoksa self-hosted mı?

Operasyonel ekibiniz Kubernetes/distributed system uzmanı değilse ClickHouse Cloud çoğu zaman daha ekonomik. Self-hosted DBA + on-call maliyeti hesaba katıldığında Cloud avantajlı. 100TB+ veri ve özel network requirement olan kurumlar için self-hosted hâlâ tercih ediliyor.

StarRocks vs Apache Doris karşılaştırması nasıl?

StarRocks Apache Doris’in fork’u olarak başladı, 2024’te bağımsız kuruldu. Cloud-native disaggregated storage ve query optimizer iyileştirmeleri StarRocks lehine. Apache Doris açık kaynak topluluk gücü ile yarışıyor; Çin pazarında dominant.

Materialized view ne zaman zararlı olur?

Çok sayıda yüksek-cardinality MV (örn. 50+ MV) maintenance overhead’i query gain’inden büyük olabilir. ClickHouse’da MV insert’i %15-25 yavaşlatıyor; 10+ MV varsa toplam %150-250 insert overhead olabilir. Önce query pattern’i ölçün, top 5-10 high-frequency query için MV oluşturun.

Ömer ÖNAL

Yazılım Mimarı | Yapay Zeka LLC. Ölçeklenebilir SaaS, .NET Core altyapıları ve Otonom AI süreçleri inşa ediyorum. Kod değil, sistem tasarlarım.

Yorum (1)

  1. Ömer ÖNAL
    Mayıs 23, 2026

    OLAP seçimi sadece TPC-H sıralaması değil. Müşterilerimde gördüğüm gerçek: ClickHouse ad-tech ve user-facing dashboard, DuckDB analist self-service + embedded analytics, StarRocks yüksek concurrency BI workload için doğru. Yanlış seçildiğinde p99 latency 3 saniyeden 200ms’ye düşmüyor, aksine ekip 6 ay ‘tuning’ diye yangın söndürüyor. Karar öncesi mutlaka concurrency ve veri boyutu profilini çıkarın. — Ömer ÖNAL

Yorum Yap

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir