जब डेटा प्रोसेस करना हो तो DuckDB मेरी पहली पसंद क्यों है

 (robinlinacre.com)
30 पॉइंट द्वारा GN⁺ 2026-01-18 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • DuckDB एक ओपन सोर्स SQL engine है जो single machine पर बड़े table data को तेज़ और सरल तरीके से प्रोसेस कर सकता है, और हाल में data engineering में व्यापक रूप से इस्तेमाल हो रहा है
  • इंस्टॉलेशन आसान है, कोई dependency नहीं है, और Python environment में तुरंत चलाया जा सकता है, इसलिए CI·test automation के लिए उपयुक्त है
  • Analytical query optimization की वजह से यह SQLite या Postgres की तुलना में अधिकतम 1,000 गुना तेज़ प्रदर्शन दिखाता है, और अलग-अलग file formats (csv, parquet, json) को सीधे query कर सकता है
  • अनुकूल SQL syntax (EXCLUDE, COLUMNS, QUALIFY, function chaining आदि) और Python API के माध्यम से complex pipelines को प्रभावी ढंग से विकसित किया जा सकता है
  • ACID compliance, high-performance UDF, PostgreSQL integration extension आदि के साथ यह medium-scale data के लिए lakehouse alternative के रूप में उभर रहा है

DuckDB का अवलोकन

  • DuckDB एक in-process SQL engine है जो analytics query optimization पर केंद्रित है
    • यह अलग server के बिना application के अंदर चलता है, और Postgres जैसी external service की ज़रूरत नहीं होती
    • यह बड़े पैमाने के join और aggregation operations के लिए विशेष रूप से अनुकूलित है, और transaction-केंद्रित engines (OLTP) की तुलना में अधिकतम 100~1,000 गुना तेज़ प्रदर्शन देता है
  • इसका प्रमुख use case csv, parquet, json जैसी बड़ी files को disk से सीधे पढ़कर batch processing करना है
  • command line से सरलता से CSV file देखना जैसे lightweight data exploration के कामों में भी इसका उपयोग किया जा सकता है

मुख्य विशेषताएँ

  • गति

    • DuckDB सबसे तेज़ ओपन सोर्स data processing engines में से एक है और benchmarks में लगातार शीर्ष स्तर पर रहता है
    • Polars, DataFusion, Spark, Dask आदि से तुलना करने पर, छोटे data में DuckDB बेहतर रहता है, जबकि बड़े data में Spark और Dask प्रतिस्पर्धी हैं

  • आसान इंस्टॉलेशन और बिना dependency

    • DuckDB single precompiled binary के रूप में उपलब्ध है, और Python में pip install duckdb से तुरंत install किया जा सकता है
    • कोई dependency नहीं होने के कारण Spark जैसे बड़े frameworks की तुलना में इसका setup बहुत आसान है
    • uv के साथ मिलाने पर 1 सेकंड के भीतर Python environment setup किया जा सकता है

  • CI और testing

    • तेज़ startup speed और lightweight nature की वजह से यह data pipelines के CI·testing environments के लिए उपयुक्त है
    • पहले Spark-आधारित tests धीमे और जटिल थे, लेकिन DuckDB के साथ environment setup सरल हो जाता है और production के साथ consistency बनाए रखना आसान होता है

  • SQL लिखने का अनुभव

    • DuckDB में SQL writing और syntax validation तेज़ी से किया जा सकता है
    • Spark local mode या AWS Athena की तुलना में यह immediate execution और iterative development के लिए अधिक अनुकूल है
    • यह autocomplete feature वाला UI भी प्रदान करता है

  • अनुकूल SQL syntax

    • DuckDB में कई user-friendly SQL extensions शामिल हैं
      • EXCLUDE, COLUMNS, QUALIFY, window function aggregation modifiers, function chaining (first_name.lower().trim()) आदि का समर्थन
    • ये सुविधाएँ complex column selection और transformation tasks को संक्षिप्त बनाती हैं

  • विविध file formats का समर्थन

    • S3·web URL·local files आदि से data को सीधे query किया जा सकता है
    • CSV type strictness options उपलब्ध हैं, जिससे unstructured input data के कारण होने वाली errors को रोका जा सकता है

  • Python API

    • Python में CTE-आधारित pipelines को step-by-step define किया जा सकता है, और हर चरण के data को आसानी से inspect किया जा सकता है
      • duckdb.sql() call के साथ SQL को chain के रूप में जोड़ा जा सकता है
      • lazy execution की वजह से performance loss के बिना intermediate results देखे जा सकते हैं
    • हर चरण के function tests संभव होने से CI testing efficiency बढ़ती है

  • ACID compliance

    • DuckDB बड़े data workloads में भी पूर्ण ACID guarantees देता है
    • इस विशेषता के कारण इसे Iceberg·Delta Lake जैसे lakehouse formats के medium-scale alternative के रूप में इस्तेमाल किया जा सकता है

  • high-performance UDF और community extensions

    • C++ में high-performance user-defined functions (UDF) लिखी जा सकती हैं
    • Community Extensions के माध्यम से INSTALL h3 FROM community जैसे command से तुरंत extensions install किए जा सकते हैं
      • उदाहरण: geospatial data के लिए hexagonal indexing (h3) support

  • documentation

    • पूरा documentation single Markdown file के रूप में उपलब्ध है, जिससे LLM training या code editor के भीतर search करना आसान हो जाता है
    • code folding feature की मदद से केवल आवश्यक भाग आसानी से copy किए जा सकते हैं

वास्तविक उपयोग और प्रभाव

  • open source Splink project में DuckDB को default backend के रूप में अपनाने के बाद
    • user issues में कमी, काम की गति में सुधार, और feature development·testing simplification हासिल हुआ

ध्यान देने योग्य extensions

  • PostgreSQL Extension: DuckDB से Postgres database को सीधे connect और query किया जा सकता है
  • pg_duckdb: Postgres के भीतर DuckDB engine को embed करके transaction processing और analytics साथ में चलाए जा सकते हैं
    • आगे चलकर Postgres index optimization और filter pushup improvements के बाद व्यापक adoption की संभावना है

संबंधित पढ़ाई

2 टिप्पणियां

 
kaydash 2026-01-18

डिस्ट्रीब्यूटेड प्रोसेसिंग के लिए बने parq को single machine पर प्रोसेस करने के मकसद से इस्तेमाल करना विडंबनापूर्ण है।
 
GN⁺ 2026-01-18
Hacker News की राय

  • मुझे DuckDB पसंद आने की कई वजहें हैं
    यह .parquet, .json, .csv फ़ाइलों, सभी को सपोर्ट करता है, और select * from 'tsa20*.csv' की तरह glob read कर सकता है, इसलिए सैकड़ों फ़ाइलों को एक फ़ाइल की तरह संभाला जा सकता है
    स्कीमा अलग होने पर भी union_by_name से उन्हें आसानी से जोड़ा जा सकता है, और CSV parser अपने-आप सही तरह से type assign कर देता है
    इसका WebAssembly वर्ज़न 2MB और CLI 16MB का है, यानी बहुत छोटा
    इसी वजह से इसे सीधे प्रोडक्ट में embed किया जा सकता है. उदाहरण के लिए Malloy जैसा
    Malloy, PowerBI या Tableau के तकनीकी वर्ज़न जैसा है, लेकिन semantic model का इस्तेमाल करके AI को बेहतर query लिखने में मदद करता है. ऐसा लगता है जैसे SQL लिखना 10 गुना आसान हो गया हो

    • DuckDB के CSV support की वजह से डेटा explore करने का मेरा तरीका पूरी तरह बदल गया
      पहले मैं schema को समझने में समय लगाता था, लेकिन अब मैं डेटा लोड करता हूँ, exploratory queries लिखता हूँ, assumptions verify करता हूँ, फिर cleaning, transformation और table creation की प्रक्रिया दोहराता हूँ
      इससे मैं बहुत तेज़ी से गहराई में जा पाता हूँ, और dead end भी जल्दी पकड़ लेता हूँ, जिससे समय बर्बाद नहीं होता
      सुना है कि CSV parser कैसे काम करता है और आगे इसमें क्या सुधार हो सकते हैं, इस पर एक paper है, लेकिन अभी तक मुझे वह मिला नहीं है
    • मैंने हाल में ClickHouse बहुत इस्तेमाल किया है, और इसमें DuckDB जैसी कई खूबियाँ हैं
      खासकर Parquet और JSON ingestion काफ़ी सुविधाजनक है, और clickhouse-local का विचार DuckDB को embed करने जैसा लगता है
      SELECT ... FROM s3Cluster(...) syntax से S3 bucket में wildcard ingest किया जा सकता है, और processing cluster nodes में distribute हो जाती है
      लगता है कि यह schema_inference_mode भी सपोर्ट करता है
      ClickHouse ने union_by_name जैसी सुविधा भी implement की है
      संबंधित दस्तावेज़: s3Cluster फ़ंक्शन, schema inference, PR #55892
    • मैंने Shaper बनाया है, जो Malloy की तरह data query और visualization को जोड़ता है
      फ़र्क बस इतना है कि Shaper अलग भाषा की जगह SQL का इस्तेमाल करता है
      DuckDB के आधार पर सिर्फ SQL से dashboard बनाया जा सकता है
      Shaper GitHub
    • मैंने ZenQuery बनाया है और अंदरूनी प्रोसेसिंग के लिए DuckDB का इस्तेमाल करता हूँ
      इसकी speed चौंकाने वाली है, और schema auto-detection ज़्यादातर सही काम करती है
      LLM natural language query से सही SQL generate कर देता है
    • यह सच में बहुत शानदार परिचय है
      मैं पहले SQLite में manual import करता था, लेकिन DuckDB की वजह से सब काफ़ी आसान हो गया

  • मैं भी DuckDB का नियमित उपयोगकर्ता हूँ
    BC तटवर्ती पर्यावरण का अध्ययन करने वाले वैज्ञानिकों के साथ काम करते हुए, हम glacier observation से लेकर deep-sea drone data तक भारी मात्रा में डेटा संभालते हैं
    हमने एक नए biodiversity data transformation tool के इंजन के रूप में DuckDB अपनाया, जिसका लक्ष्य डेटा को Darwin Core standard में transform और validate करना है
    हम schema के आधार पर DuckDB tables को dynamically बनाते हैं और डेटा import करते हैं. असफल होने पर row level पर कारण भी बताते हैं
    transformation और validation भी पूरी तरह DuckDB के भीतर होता है
    इससे हमने कहीं अधिक तेज़, शक्तिशाली, और browser में भी चल सकने वाला application बनाया
    field researchers इसे iPad browser में offline भी इस्तेमाल कर सकते हैं
    DuckDB की वजह से SQL पर भरोसा होने लगा है कि वह भारी काम संभाल लेगा
    जहाँ type safety कम पड़ती है, वहाँ parsing और testing से उसकी भरपाई करते हैं
    इस प्रोजेक्ट का उद्देश्य यह है कि वैज्ञानिक एक साझा टूल से biodiversity और genomic data का विश्लेषण करें और उन्हें public repositories में प्रकाशित कर सकें

    • मौजूदा datasets किस format में हैं, यह जानने की जिज्ञासा है
      मैं वैज्ञानिक डेटा प्रोसेसिंग में अक्सर HDF5 से काम करता हूँ, लेकिन DuckDB इसे मूल रूप से सपोर्ट नहीं करता
      मौजूदा extension धीमा है और सुविधाएँ भी कम हैं, इसलिए मैंने C++ template से नया extension बनाया है
      मैं ऐसे लोगों की तलाश में हूँ जो सहयोग में रुचि रखते हों
    • सोच रहा हूँ कि यही काम Polars से करने पर क्या फ़ायदे होंगे
      व्यक्तिगत रूप से मुझे Polars का syntax SQL से कहीं ज़्यादा सहज लगता है, इसलिए सोच रहा हूँ कि DuckDB को आज़माना वाकई worthwhile है या नहीं

  • हम Bluesky की analytics और feed processing DuckDB से करते हैं
    तेज़ी से results पाने के लिए Apache Arrow interface इस्तेमाल करते हैं, और SQG से DuckDB SQL queries से सीधे code generate करते हैं

    • आपका tech stack जानने की इच्छा है. अगर इसकी internal architecture पर कोई लेख हो तो पढ़ना चाहूँगा. HN tool भी प्रभावशाली है

  • मैं Java प्रोजेक्ट manifold-sql का परिचय देना चाहता हूँ
    इससे DuckDB SQL को type-safe inline लिखा जा सकता है
    आप SQL को सीधे code में रख सकते हैं और .fetch() से result iterate कर सकते हैं, इसलिए बिना किसी मध्यवर्ती layer के चीज़ें साफ़-सुथरी रहती हैं

  • लेखक की बात बुनियादी data processing के लिए सही लगती है, लेकिन
    “ज़्यादातर tabular data को एक single machine पर प्रोसेस किया जा सकता है” वाला हिस्सा बहस योग्य है
    डेटा का विस्तार, pivot या augmentation करते-करते जल्दी memory overflow (OOM) हो सकता है
    और “नई data engineering के लिए SQL पहली पसंद होनी चाहिए” वाला दावा भी जटिल analytics पर पूरी तरह फिट नहीं बैठता

    • मैं ही लेख का लेखक हूँ
      dataframe API जैसे Polars या pandas के अपने फ़ायदे हैं, लेकिन ecosystem standardize नहीं है, इसलिए pipelines बार-बार दोबारा लिखनी पड़ती हैं, यही समस्या है
      ज़्यादातर डेटा 10GB से कम होता है, इसलिए single machine पर आराम से प्रोसेस हो सकता है
      कई बार Spark का इस्तेमाल ज़रूरत से ज़्यादा कर लिया जाता है
      मेरा कहना बस इतना है कि “पहले DuckDB से कोशिश करके देखो”. सरल मामलों में यह तेज़ और efficient है
    • ML या visualization जैसी उन्नत analytics के लिए dataframe ज़्यादा उपयुक्त हो सकता है
      साधारण pipeline processing के लिए SQL अच्छा है, लेकिन readability व्यक्ति-दर-व्यक्ति बदलती है
      मुझे dataframe वाला तरीका कहीं ज़्यादा readable लगता है
    • SQL आज भी सीखने में आसान है, और data modeling का ज़्यादातर काम SQL में ही होता है
      ingestion की तरफ़ Python या Scala ज़्यादा दिखते हैं, लेकिन SQL गायब नहीं होने वाला
    • मैं 500GB Parquet डेटा को DuckDB से प्रोसेस कर रहा हूँ, और 50GB RAM वाले desktop पर भी यह smooth और fast चलता है
      OOM शायद केवल बहुत extreme मामलों में ही समस्या बनेगा
    • Polars में भी इन फ़ायदों का बड़ा हिस्सा मौजूद है, और यह GPU व distributed backend तक सपोर्ट करता है
      DuckDB जितना ध्यान पा रहा है, उसके मुकाबले Polars को कम आंका जा रहा है

  • मैं डेटा प्रोसेसिंग बहुत करता हूँ, और ज़्यादातर Polars इस्तेमाल करता हूँ
    यह बहुत तेज़ है, और pandas की तरह इसमें कई ऐसे functions हैं जिन्हें SQL में लागू करना मुश्किल है
    Python functions भी सीधे इस्तेमाल किए जा सकते हैं
    भले ही DuckDB का performance बराबर हो, फिर भी SQL की expression limitations को लेकर झिझक होती है

    • मेरे अनुभव में DuckDB कहीं ज़्यादा तेज़ और संक्षिप्त था
      यह standalone है, इसलिए install भी आसान है, और tuning या learning curve लगभग नहीं के बराबर है

  • मैंने mainframe से बनी बुरी तरह formatted Excel files को DuckDB में लोड किया,
    all_varchar option के साथ यह एक सेकंड से भी कम समय में load हो गईं
    Excel अभी भी फ़ाइल खोल ही रहा है

  • DuckDB शानदार है, लेकिन dynamic extension loading code signing से टकराता है, इसलिए commercial apps में इसका इस्तेमाल मुश्किल हो जाता है
    और spatial extension में LGPL components होने से licensing issue भी है
    अच्छा होगा अगर Apache Arrow की तरह ज़रूरत के हिसाब से package units में features को compose किया जा सके
    उदाहरण: HTTP पर GB/s array transfer के लिए Arrow Flight, file sharing के लिए Arrow IPC, Parquet read के लिए अलग trait
    DuckDB का SQL type system Arrow से अलग है, इसलिए type mismatch की समस्या आ सकती है
    Arrow ज़्यादातर भाषाओं में native libraries देता है

  • अरबों transaction data rows और 30 columns वाली एक single table में
    यह जानना है कि WHERE condition से filtered pages को तेज़ी से निकाला जा सकता है या नहीं
    Postgres में साधारण count(*) भी बहुत समय लेता है

    • इस पैमाने पर DuckDB में भी शायद कुछ सेकंड के भीतर काम पूरा हो जाएगा
      धीमापन मुझे सिर्फ़ complex joins या बहुत सारी files पर glob processing में दिखा है
    • count की speed बढ़ानी हो तो index से ज़्यादा periodic caching उपयोगी हो सकती है
      अगर WHERE condition साधारण column-value pairs पर है, तो यह काफ़ी तेज़ होना चाहिए

  • DuckDB सिर्फ़ तेज़ DB नहीं है, इसका developer experience (devx) भी शानदार है
    इसे शुरू करना आसान है, इसलिए ecosystem तेज़ी से बढ़ रहा है
    Web/WASM integration भी प्रभावशाली है
    उम्मीद है ऐसे छोटे engines और आएँ, ताकि competition और innovation जारी रहे