DuckDB veri işlerken neden ilk tercihim

 (robinlinacre.com)
30 puan yazan GN⁺ 2026-01-18 | 2 yorum | WhatsApp'ta paylaş
  • DuckDB, tek bir makinede büyük tablo verilerini hızlı ve basit şekilde işleyebilen açık kaynaklı bir SQL motoru olarak son dönemde veri mühendisliğinde yaygın biçimde kullanılıyor
  • Kurulumu kolaydır, bağımlılığı yoktur ve Python ortamında anında çalıştırılabildiği için CI ve test otomasyonu için uygundur
  • Analitik sorgu optimizasyonu sayesinde SQLite veya Postgres'ten 1.000 kata kadar daha hızlı performans gösterir ve çeşitli dosya biçimleri (csv, parquet, json) doğrudan sorgulanabilir
  • Kullanıcı dostu SQL söz dizimi (EXCLUDE, COLUMNS, QUALIFY, fonksiyon zincirleme vb.) ve Python API ile karmaşık pipeline'lar verimli şekilde geliştirilebilir
  • ACID uyumluluğu, yüksek performanslı UDF'ler, PostgreSQL entegrasyon uzantısı gibi özelliklerle orta ölçekli veriler için bir lakehouse alternatifi olarak öne çıkıyor

DuckDB'ye genel bakış

  • DuckDB, analitik sorgu optimizasyonuna odaklanan bir in-process SQL motorudur
    • Ayrı bir sunucu olmadan uygulamanın içinde çalışır; Postgres gibi harici bir servise ihtiyaç duymaz
    • Büyük ölçekli join ve aggregation işlemlerinde uzmanlaşmıştır ve işlem odaklı motorlara (OLTP) göre 100 ila 1.000 kat daha hızlı performans sunar
  • Başlıca kullanım senaryoları, csv, parquet, json gibi büyük dosyaları diskte doğrudan okuyarak toplu işleme (batch processing) yapmaktır
  • Komut satırından CSV dosyalarını hızlıca sorgulamak gibi hafif veri keşfi için de kullanılabilir

Başlıca özellikler

  • Hız

    • DuckDB, en hızlı açık kaynak veri işleme motorlarından biri olup benchmark'larda üst sıralarda yer alır
    • Polars, DataFusion, Spark, Dask gibi araçlarla karşılaştırıldığında, küçük veride DuckDB öne çıkar, büyük veride ise Spark ve Dask rekabetçidir

  • Kolay kurulum ve bağımlılıksız yapı

    • DuckDB, tek bir önceden derlenmiş binary olarak sunulur ve Python'da pip install duckdb ile anında kurulabilir
    • Bağımlılık gerektirmemesi, Spark gibi büyük framework'lere kıyasla kurulumu son derece kolaylaştırır
    • uv ile birlikte kullanıldığında 1 saniyenin altında bir Python ortamı kurulabilir

  • CI ve test

    • Hızlı açılış süresi ve hafif yapısı sayesinde veri pipeline'larının CI ve test ortamları için uygundur
    • Geçmişte Spark tabanlı testler yavaş ve karmaşıktı; DuckDB ise ortam kurulumunu basitleştirir ve prodüksiyonla tutarlılığı korumayı kolaylaştırır

  • SQL yazma deneyimi

    • DuckDB ile SQL yazımı ve söz dizimi doğrulaması hızlı şekilde yapılabilir
    • Spark local mode veya AWS Athena'ya göre anında çalıştırma ve iteratif geliştirme açısından daha elverişlidir
    • Otomatik tamamlama özelliğine sahip bir UI sunar

  • Kullanıcı dostu SQL söz dizimi

    • DuckDB, çok sayıda kullanıcı dostu SQL uzantısı içerir
      • EXCLUDE, COLUMNS, QUALIFY, window function aggregation modifier'ları, fonksiyon zincirleme (first_name.lower().trim()) gibi özellikleri destekler
    • Bu özellikler, karmaşık sütun seçme ve dönüştürme işlerini kısa ve anlaşılır hale getirir

  • Çeşitli dosya biçimi desteği

    • S3, web URL'leri ve yerel dosyalar üzerinden veriler doğrudan sorgulanabilir
    • CSV tip katılığı seçenekleri sunarak düzensiz girdi verilerinden kaynaklanan hataları önler

  • Python API

    • Python'da CTE tabanlı pipeline'lar adım adım tanımlanabilir ve her aşamadaki veriler kolayca incelenebilir
      • duckdb.sql() çağrısıyla SQL zincirleme biçimde bağlanabilir
      • Tembel çalıştırma (lazy execution) sayesinde performans kaybı olmadan ara sonuçlar incelenebilir
    • Her aşamadaki fonksiyonlar test edilebildiği için CI test verimliliği artar

  • ACID uyumluluğu

    • DuckDB, büyük hacimli veri işlemlerinde bile tam ACID garantisi sunar
    • Bu özelliği sayesinde Iceberg ve Delta Lake gibi lakehouse formatları için orta ölçekli pratik bir alternatif olabilir

  • Yüksek performanslı UDF'ler ve topluluk uzantıları

    • C++ ile yüksek performanslı kullanıcı tanımlı fonksiyonlar (UDF) yazılabilir
    • Community Extensions aracılığıyla INSTALL h3 FROM community gibi komutlarla uzantılar anında kurulabilir
      • Örnek: coğrafi veriler için altıgen indeksleme (h3) desteği

  • Dokümantasyon

    • Tüm dokümantasyon tek bir Markdown dosyası olarak sunulur; bu da LLM eğitimi veya kod editörü içinde arama açısından kullanışlıdır
    • Kod katlama özelliği sayesinde yalnızca gereken kısımlar kolayca kopyalanabilir

Gerçek kullanım ve etkisi

  • Açık kaynak Splink projesinde DuckDB'nin varsayılan backend olarak benimsenmesi sonucunda
    • Kullanıcı sorunları azaldı, çalışma hızı arttı, özellik geliştirme ve testler sadeleşti

Dikkat çeken uzantılar

  • PostgreSQL Extension: DuckDB içinden Postgres veritabanına doğrudan bağlanıp sorgu çalıştırılabilir
  • pg_duckdb: DuckDB motorunu Postgres'in içine gömerek işlemsel ve analitik iş yüklerini birlikte çalıştırmayı mümkün kılar
    • Gelecekte Postgres indeks optimizasyonu ve filter pushup iyileştirmeleri sonrasında geniş çaplı benimsenme potansiyeli bulunuyor

İlgili okumalar

2 yorum

 
kaydash 2026-01-18

Dağıtık işleme için olan Parquet'yi tek bir makinede işlemek amacıyla kullanmak ironik görünüyor.
 
GN⁺ 2026-01-18
Hacker News yorumları

  • DuckDB’yi sevmemin birçok nedeni var
    .parquet, .json, .csv dosyalarının hepsini destekliyor ve select * from 'tsa20*.csv' gibi glob okuma yapabildiği için yüzlerce dosyayı tek bir dosyaymış gibi ele alabiliyorsunuz
    Şema farklı olsa bile union_by_name ile kolayca birleştirilebiliyor ve CSV ayrıştırıcısı tipleri otomatik olarak oldukça iyi belirliyor
    WebAssembly sürümü 2MB, CLI ise 16MB ile çok küçük
    Bu sayede doğrudan ürünün içine gömülebiliyor. Örneğin Malloy gibi
    Malloy, PowerBI veya Tableau’nun daha teknik bir sürümü gibi; anlamsal model kullanarak yapay zekanın daha iyi sorgular yazmasına yardımcı oluyor. SQL yazmayı 10 kat daha kolaylaştırıyormuş gibi hissettiriyor

    • DuckDB’nin CSV desteği sayesinde veriyi keşfetme biçimim tamamen değişti
      Eskiden önce şemayı anlamaya zaman harcardım; şimdi ise veriyi yükleyip keşif sorguları yazıyor, varsayımlarımı doğruluyor ve ardından temizleme, dönüştürme ve tablo oluşturma sürecini tekrar ediyorum
      Bu sayede çok daha hızlı derine inebiliyor ve çıkmaz sokakları da erken fark ederek zaman kaybını azaltıyorum
      CSV ayrıştırıcısının nasıl çalıştığını ve ileride nasıl geliştirilebileceğine dair bir makale olduğunu duymuştum ama henüz bulamadım
    • Son zamanlarda ClickHouse’u da epey kullandım ve DuckDB ile benzer birçok avantajı var
      Özellikle Parquet ve JSON ingestion oldukça rahat, clickhouse-local da DuckDB’yi gömülü kullanma fikrine benziyor
      SELECT ... FROM s3Cluster(...) söz dizimiyle S3 bucket’larından wildcard ingest yapılabiliyor ve işlem küme düğümlerine dağıtılıyor
      Görünüşe göre schema_inference_mode da destekleniyor
      ClickHouse, union_by_name benzeri bir özelliği de hayata geçirdi
      İlgili belgeler: s3Cluster fonksiyonu, schema inference, PR #55892
    • Ben de Shaper’ı geliştirdim; Malloy’un fikrine benzer şekilde veri sorgulama ile görselleştirmeyi birleştiriyor
      Ancak Shaper, ayrı bir dil yerine SQL kullanıyor
      DuckDB tabanlı olarak yalnızca SQL ile dashboard oluşturabiliyorsunuz
      Shaper GitHub
    • Ben ZenQuery’yi yaptım ve iç tarafta DuckDB kullanıyorum
      Hızı inanılmaz ve otomatik şema algılama çoğu zaman doğru çalışıyor
      LLM, doğal dille verilen sorgudan doğru SQL’i üretiyor
    • Bu gerçekten harika bir tanıtım
      Ben SQLite ile elle import yapıyordum ama DuckDB sayesinde işler çok daha basit hale geldi

  • Ben de DuckDB’yi sık kullanan biriyim
    BC kıyı çevresini araştıran bilim insanlarıyla çalışıyorum ve buzul gözlemlerinden derin deniz drone verilerine kadar çok büyük miktarda veriyle uğraşıyoruz
    Yeni bir biyolojik çeşitlilik veri dönüştürme aracının motoru olarak DuckDB’yi seçtik; hedefimiz veriyi Darwin Core standardına dönüştürmek ve doğrulamak
    DuckDB tablolarını şema temelli olarak dinamik biçimde oluşturup veriyi içe aktarıyoruz. Başarısız olursa satır bazında nedenini bildiriyor
    Dönüştürme ve doğrulamanın tamamını da DuckDB içinde yapıyoruz
    Bu sayede çok daha hızlı, güçlü ve tarayıcıda da çalışabilen bir uygulama geliştirdik
    Saha araştırmacıları bunu iPad tarayıcısında çevrimdışı da kullanabiliyor
    DuckDB sayesinde ağır işi SQL’in yaptığına güvenme hissi oluşuyor
    Tip güvenliği eksik kalan yerleri ayrıştırma ve testlerle telafi ediyoruz
    Bu projenin amacı, bilim insanlarının biyolojik çeşitlilik ve genomik verileri ortak araçlarla analiz edip herkese açık depolara yayımlayabilmesi

    • Mevcut veri kümeleri hangi formatta, merak ettim
      Ben bilimsel veri işlemede sık sık HDF5 ile uğraşıyorum ama DuckDB varsayılan olarak HDF5 desteklemiyor
      Mevcut eklenti yavaş ve özellikleri yetersizdi; bu yüzden C++ template’leriyle yeni bir eklenti yazdım
      Bu konuda iş birliği yapmak isteyenleri arıyorum
    • Aynı iş için Polars kullansanız ne avantajı olurdu, merak ediyorum
      Şahsen Polars söz dizimini SQL’den çok daha rahat buluyorum; o yüzden DuckDB’yi denemeye değer mi diye düşünüyorum

  • Bluesky analiz ve akış işleme tarafında DuckDB kullanıyoruz
    Sonuçları hızlı almak için Apache Arrow arayüzünü kullanıyor ve SQG ile DuckDB SQL sorgularından doğrudan kod üretiyoruz

    • Teknoloji yığınınızı merak ettim. İç mimariyi anlatan bir yazı var mı? HN aracı da etkileyici görünüyor

  • Java projesi olan manifold-sql’i tanıtmak isterim
    DuckDB SQL’i type-safe biçimde inline yazmanıza izin veriyor
    SQL’i doğrudan kodun içine koyup .fetch() ile sonuçlar üzerinde dolaşabiliyorsunuz; arada ekstra katman olmaması hoş

  • Yazarın iddiası temel veri işleme için makul,
    ancak “çoğu tablo verisi tek bir makinede işlenebilir” kısmı tartışmalı
    Veriyi büyütme, pivot etme veya zenginleştirme gibi işler yapınca hızla bellek taşması (OOM) yaşayabiliyorsunuz
    Ayrıca “SQL yeni veri mühendisliğinde ilk tercih olmalı” iddiası da karmaşık analizlere çok uygun değil

    • Yazının sahibi benim
      Polars veya pandas gibi dataframe API’lerinin de birçok avantajı var ama ekosistem standardize olmadığı için pipeline’ları sık sık yeniden yazmak gerekiyor
      Verilerin çoğu 10GB’ın altında olduğu için tek makinede rahatça işlenebiliyor
      Spark çoğu zaman gereğinden fazla kullanılıyor
      Benim yaklaşımım “önce DuckDB ile deneyin” yönünde. Basit durumlarda hızlı ve verimli
    • ML veya görselleştirme gibi ileri analizlerde dataframe yaklaşımı daha uygun
      Basit pipeline işlemlerinde SQL iyi ama okunabilirlik kişiden kişiye değişir
      Ben dataframe tarafını çok daha okunaklı buluyorum
    • SQL hâlâ öğrenmesi kolay ve veri modelleme işlerinin çoğu SQL ile yapılıyor
      ingestion tarafında Python veya Scala yaygın ama SQL ortadan kaybolmayacak
    • Ben 500GB Parquet verisini DuckDB ile işliyorum ve 50GB RAM’li masaüstünde bile akıcı ve hızlı çalışıyor
      OOM muhtemelen ancak uç senaryolarda sorun olur
    • Polars da bu avantajların çoğuna sahip ve GPU ile dağıtık backend desteği de var
      DuckDB ne kadar ilgi görüyorsa, Polars da bir o kadar hak ettiği ilgiyi görmüyor

  • Ben çok veri işliyorum ve çoğunlukla Polars kullanıyorum
    Çok hızlı ve pandas gibi, SQL ile ifade etmesi zor birçok işlev sunuyor
    Python fonksiyonlarını da doğrudan kullanabiliyorsunuz
    DuckDB aynı performansı verse bile SQL’in ifade sınırları yüzünden tereddüt ediyorum

    • Benim deneyimimde DuckDB çok daha hızlı ve derli topluydu
      Bağımsız çalıştığı için kurulumu da kolay ve ayar/tuning ya da öğrenme eğrisi neredeyse yok

  • Mainframe’in ürettiği biçimi bozuk Excel dosyalarını DuckDB ile içe aktardım,
    all_varchar seçeneğiyle bir saniyeden kısa sürede yüklendi
    Excel ise dosyayı hâlâ açmaya çalışıyordu

  • DuckDB harika ama dinamik eklenti yükleme kod imzalama ile çakıştığı için ticari uygulamalarda kullanımı zor
    Ayrıca uzamsal eklenti LGPL bileşenleri kullandığı için lisans tarafında da sorun çıkıyor
    Apache Arrow’daki gibi gereken özellikleri paket bazında birleştirebilmek güzel olurdu
    Örneğin: HTTP üzerinden GB/s düzeyinde dizi aktarımı için Arrow Flight, dosya paylaşımı için Arrow IPC, Parquet okuma için ayrı bir trait eklemek
    DuckDB’nin SQL tip sistemi Arrow’dan farklı olduğu için tip uyumsuzluğu sorunları çıkabiliyor
    Arrow çoğu dil için native kütüphaneler sunuyor

  • 30 sütunlu, milyarlarca işlem verisi içeren tek bir tabloda
    WHERE koşuluyla filtrelenmiş sayfaları hızlıca çekmek mümkün mü, merak ediyorum
    Postgres’te basit bir count(*) bile uzun sürüyor

    • Bu ölçekte DuckDB’nin de birkaç saniye içinde bitireceğini tahmin ederim
      Yavaş kaldığını gördüğüm durumlar sadece karmaşık join’ler veya çok sayıda dosyada glob işlemleriydi
    • count hızını artırmak için indeks yerine periyodik önbellekleme daha iyi olabilir
      WHERE koşulları basit sütun-değer çiftlerinden oluşuyorsa oldukça hızlı çalışacaktır

  • DuckDB sadece hızlı bir veritabanı değil, geliştirici deneyimi (devx) de çok güçlü
    Başlaması kolay olduğu için ekosistemi hızla büyüyor
    Web/WASM entegrasyonu da etkileyici
    Böyle küçük motorların daha fazla ortaya çıkıp rekabeti ve yeniliği sürdürmesini isterim