DuckDB Nedir? Embedded Analytics ve Local-First Veri 2026

DuckDB nedir sorusunun en kısa cevabı: süreç içi (in-process) çalışan, sütun tabanlı, OLAP odaklı açık kaynak bir analitik veritabanı motorudur. SQLite gibi tek dosyaya sığar, sunucu kurmadan kütüphane olarak yüklenir; ancak SQLite’ın aksine satır tabanlı OLTP yerine vektörize sütunlu OLAP için tasarlanmıştır. 2026 itibarıyla DuckDB 1.x sürümü kararlı API garantisi taşıyor, GitHub’da 20 binin üzerinde yıldız topluyor ve PyPI üzerinden aylık milyonlarca indirme görüyor. CWI Amsterdam’da doğan proje, “local-first” veri işleme akımının fiili standardı haline geldi: Parquet, CSV, JSON, Arrow ve Iceberg dosyalarını doğrudan sorgular, milyarlarca satırı dizüstüde saniyeler içinde işler, bulut sütun depolarına (S3, GCS, Azure Blob) yetkili kimliklerle erişir.

Analitik mimarinin geleneksel resmi şuydu: veriler önce bir warehouse’a (Snowflake, BigQuery) yüklenir, sonra BI veya notebook üzerinden sorgulanır. DuckDB bu zinciri kısaltıyor; veri zaten Parquet olarak object storage’da duruyorsa, ayrı warehouse’a kopyalamadan analiz mümkün. Bu yazıda mimari, performans, rakip karşılaştırması, kurulum, gerçek senaryolar, MotherDuck entegrasyonu ve karar çerçevesi var.

DuckDB Nedir ve Neden 2026’da Önemli

DuckDB, Mark Raasveldt ve Hannes Mühleisen tarafından 2018’de CWI’da başlatılan açık kaynak (MIT lisansı) bir embedded analitik veritabanıdır. “Embedded” ifadesi kritik: ayrı sunucu süreci yok, uygulamanızla aynı bellek alanında çalışır. Python’da import duckdb, Node.js’te require('duckdb'), R’da library(duckdb) komutuyla yüklenir. Veriyi diske yazmak isteğe bağlıdır. Analitik için SQLite eşdeğeri olarak tanımlanır: ağ gecikmesi yok, kimlik doğrulama katmanı yok, dağıtım maliyeti sıfır.

2026 verilerine göre yükselişi destekleyen üç faktör var. Birincisi, Parquet ve Arrow ekosisteminin olgunlaşması: veri ekipleri ham veriyi warehouse yerine object storage’da tutmaya yöneliyor; DuckDB bu formatları natif sorguluyor. İkincisi donanım: 64 GB RAM tüketici sınıfı dizüstüde mevcut, NVMe SSD’ler 5-7 GB/s okuma sunuyor; bugünün dizüstüsü 5 yıl öncesinin orta ölçekli kümesinden güçlü. Üçüncüsü, MotherDuck gibi yönetilen hizmetlerin bulut ölçeklenebilirliği sağlaması. Stack Overflow 2025 Survey’inde DuckDB “most admired database” kategorisinde ilk beşe girdi.

Mimari farklılaşma noktaları nettir. DuckDB sütun tabanlı saklama, vektörize yürütme (2048 satırlık bloklar halinde işleme), MVCC tabanlı transaction ve maliyet tabanlı sorgu optimizasyonu sunar. SQL desteği PostgreSQL diyalektine yakın; window, CTE, recursive CTE, JSON path, regex, full-text search, vector similarity (HNSW) hepsi mevcut. Eklenti sistemiyle httpfs, parquet, json, icu, fts, spatial, vss, postgres_scanner, mysql_scanner, sqlite_scanner modülleri tek komutla yüklenir.

Özellik	Detay	Notlar
Lisans	MIT	Tam açık kaynak, ticari kullanım serbest
Mimari	Embedded, in-process	Sunucu süreci yok
Saklama	Columnar, snappy/zstd sıkıştırma	Tipik 3-10x sıkıştırma oranı
İşletim sistemi	Linux, macOS, Windows, WASM	Tarayıcıda da çalışır
Dil bağlamaları	Python, R, Node.js, Java, Go, Rust, C/C++, Julia, Swift	Tüm bağlamalar resmi
SQL diyalekti	PostgreSQL benzeri	Window, CTE, JSON, regex
Format desteği	Parquet, CSV, JSON, Arrow, Iceberg, Delta	Doğrudan SQL sorgu
Transaction	ACID, MVCC	Tek yazıcı, çoklu okuyucu
Maks veri seti	Disk ile sınırlı (TB ölçeği)	Out-of-core spilling destekli

Mimari: Vektörize Yürütme ve Sütunlu Saklama

Geleneksel satır tabanlı veritabanları (PostgreSQL, MySQL) bir kaydı tüm sütunlarıyla saklar; OLTP iş yükü için optimaldir. OLAP’ta tipik sorgu “1 milyar satırdan 3 sütun seç, grupla, topla” gibi görünür. Sütunlu saklama bu örüntü için 10-100 kat avantaj sağlar: yalnız ilgili sütunlar diskten okunur, sıkıştırma oranı yüksektir, CPU cache verimli kullanılır.

DuckDB’nin ayırt edici tasarım kararı “vectorized execution”dır. Standart bir SQL motoru her satırı tek tek işler (tuple-at-a-time), bu da virtual function call overhead’i yaratır. DuckDB ise 2048 satırlık “vector” bloklarını birlikte işler. Modern CPU’ların SIMD (Single Instruction Multiple Data) talimat setlerini sömürür, cache-friendly bellek erişim örüntüsü kurar. Bu yaklaşım MonetDB ve Vectorwise’da prototipe edilmiş, DuckDB’de açık kaynak olarak olgunlaştırılmıştır.

Sorgu yaşam döngüsü dört aşamadan oluşur: parser, planner, optimizer (maliyet tabanlı yeniden yazım, predicate ve projection pushdown, join ordering) ve executor (fiziksel operatörler vektör üzerinden). Optimizer filter pushdown ile WHERE koşulunu Parquet okumasına iter, yalnız gereken sütunları getirir, küçük tabloyu inner taraf yapar. Sonuç: 100 GB Parquet’i tarayan agregasyon dizüstüde dakikalar yerine saniyeler içinde tamamlanır.

Operatör	Saklama Modeli	Tipik OLAP Performansı	Bellek Kullanımı
PostgreSQL (satır)	Row	1x (taban)	Düşük
SQLite (satır)	Row	0.8-1.2x	Düşük
MySQL (satır)	Row	0.7-1.0x	Orta
ClickHouse (sütun)	Columnar	20-50x	Yüksek
DuckDB (sütun + vektör)	Columnar, vectorized	15-40x	Orta-yüksek
Snowflake	Columnar (warehouse)	10-30x	Bulut

DuckDB’nin out-of-core (bellekten büyük) iş yükleri için spilling mekanizması vardır: ara sonuçlar geçici diske yazılır, hash table’lar partition’lara bölünür. Yine de bellek üstünde çalışmak her zaman daha hızlıdır; pratik bir kural olarak DuckDB için RAM’in 2-3 katı veri seti boyutu rahat bir tavandır. Daha büyük ölçeklerde Apache Spark veya bulut warehouse’lara geçiş düşünülmelidir; Spark ve Kafka tabanlı big data pipeline mimarisi bu eşik aşıldığında devreye girer. Akademik literatür arka planı için orijinal DuckDB VLDB makalesi motorun tasarım kararlarını detaylandırır.

Performans: Benchmark Sonuçları ve Pratik Ölçümler

DuckDB performansını üç bağımsız benchmark üzerinden değerlendirebiliriz: TPC-H, ClickBench ve özel veri yükü testleri. TPC-H decision support için 22 sorgu seti; ClickBench, ClickHouse ekibinin 100 milyon satırlık web tıklama verisi üzerinden 43 sorguyla motorları kıyaslayan modern benchmark’ıdır. DuckDB her ikisinde de tek makinede üst sıralarda; embedded kategoride tartışmasız liderdir.

TPC-H scale factor 100 (yaklaşık 100 GB) iş yükünde, 64 GB RAM ve 16 çekirdekli bir makinede DuckDB tüm 22 sorguyu tipik olarak 2-5 dakikada tamamlar. Aynı donanımda PostgreSQL aynı sorguları saatlerce çalıştırır; kategori farkıdır. ClickBench resmî sonuç sayfası üzerinden DuckDB tek-sorgu sonuçları 0.2-2 saniye aralığında; cold start ile hot start arasındaki fark Parquet metadata cache’i nedeniyle 2-5 kat olabilir.

Veri Seti	Boyut	Donanım	DuckDB Süre	PostgreSQL Süre
TPC-H SF10	~10 GB	16 GB RAM, 8 core	20-30 saniye	15-25 dakika
TPC-H SF100	~100 GB	64 GB RAM, 16 core	2-5 dakika	2-6 saat
ClickBench (hits.parquet)	~14 GB	32 GB RAM, 16 core	0.2-2 sn/sorgu	5-60 sn/sorgu
NYC Taxi (1.5 milyar satır)	~50 GB Parquet	32 GB RAM	3-10 sn	Pratik değil
1 milyar satır agregasyon	~30 GB	16 GB RAM	5-15 sn	20-60 dakika

Pratik performans için üç optimizasyon kuralı vardır. Birincisi, mümkün olduğunca Parquet kullanın; CSV okuması Parquet’ten 3-10 kat yavaştır. İkincisi, predicate pushdown’dan yararlanın: WHERE date BETWEEN '2025-01-01' AND '2025-03-31' tarzı filtreler Parquet row group metadata’sından partisyon atlamaya neden olur. Üçüncüsü, gerek yoksa veriyi DuckDB native formatına (.duckdb dosyası) yükleyin; native format Parquet’ten %20-40 daha hızlıdır çünkü ek sıkıştırma stratejileri (RLE, FSST, ALP) uygular.

Kurulum ve İlk Sorgular

DuckDB kurulumu tek komutla halledilir. Python’da pip install duckdb, R’da install.packages("duckdb"), Node.js’te npm install duckdb. CLI ikili dosyası GitHub release sayfasından platforma uygun arşiv olarak indirilebilir; macOS için brew install duckdb da çalışır. Toplam ikili dosya boyutu ~30 MB; ek bağımlılık yoktur. Resmi DuckDB dokümantasyonu her dil için hızlı başlangıç örneklerini barındırır.

İlk sorgu deneyimini somutlaştıralım. Bir dizüstüde 5 GB Parquet dosyası olduğunu varsayın:

• Yöntem 1 — CLI: duckdb komutuyla shell aç, SELECT product_id, SUM(amount) FROM 'sales.parquet' GROUP BY product_id ORDER BY 2 DESC LIMIT 10; yaz. Parquet dosyası tablo gibi sorgulanır, yükleme gerekmez.
• Yöntem 2 — Python: import duckdb; df = duckdb.sql("SELECT * FROM 'sales.parquet' WHERE region = 'EU'").df(). Sonuç pandas DataFrame’e çevrilir.
• Yöntem 3 — Persistent database: duckdb my.duckdb ile kalıcı dosya aç, CREATE TABLE sales AS SELECT * FROM 'sales.parquet';. Sorgular bu native tablo üzerinden daha hızlı koşar.
• Yöntem 4 — Remote Parquet: INSTALL httpfs; LOAD httpfs; sonrasında SELECT * FROM 'https://example.com/data.parquet' LIMIT 100; ile uzak dosya doğrudan sorgulanır.
• Yöntem 5 — S3: CREATE SECRET (TYPE S3, KEY_ID '...', SECRET '...', REGION 'eu-west-1'); sonrasında SELECT * FROM 's3://bucket/path/*.parquet' WHERE ....

Eklenti ekosistemi DuckDB’nin gücünü katlar. Yaygın eklentiler şunlardır:

• httpfs: HTTP/S3/GCS/Azure Blob üzerinden uzak dosya okuma. Ne zaman seç: bulut data lake’den doğrudan sorgu.
• parquet: Parquet okuma/yazma (varsayılan bundled). Avantaj: şema evolution, predicate pushdown.
• json: JSON okuma, jq tarzı path sorguları. Dezavantaj: derin nested için performans düşer.
• icu: Unicode collation, tarih/saat dilimi. Ne zaman seç: Türkçe sıralama veya çok dilli metin.
• fts: Full-text search, BM25 scoring. Avantaj: hafif arama, Elasticsearch gerekmez.
• vss: Vektör similarity search, HNSW indeksi. Ne zaman seç: embedding tabanlı semantik arama.
• spatial: PostGIS uyumlu spatial fonksiyonlar. Avantaj: harita verisi analizi.
• postgres_scanner / mysql_scanner / sqlite_scanner: Diğer veritabanlarından canlı federated sorgu.

DuckDB vs SQLite vs ClickHouse vs Polars

“DuckDB yerine X kullansam?” sorusu en sık duyulan karşılaştırmadır. Kısa cevap: her aracın sweet-spot’u farklıdır. SQLite OLTP için, ClickHouse büyük ölçekli sunucu OLAP için, Polars DataFrame manipülasyonu için, DuckDB embedded OLAP için tasarlanmıştır. Aşağıdaki matris karar verirken yardımcı olacak somut farkları gösterir.

Özellik	DuckDB	SQLite	ClickHouse	Polars
Birincil amaç	Embedded OLAP	Embedded OLTP	Sunucu OLAP	DataFrame işleme
Saklama	Sütun	Satır	Sütun	Sütun (Arrow)
Sunucu süreci	Hayır	Hayır	Evet	Hayır
SQL desteği	Kapsamlı (PG)	Standart SQL	Genişletilmiş SQL	Sınırlı (LazyFrame)
Maks praktik veri	~1 TB tek node	~1 TB	PB ölçeği cluster	~RAM*5
OLAP performansı	Çok yüksek	Düşük	En yüksek	Yüksek
OLTP performansı	Düşük	Çok yüksek	Düşük	Yok
Kurulum karmaşası	Sıfır	Sıfır	Yüksek	Sıfır
Maliyet (open source)	Ücretsiz	Ücretsiz	Ücretsiz	Ücretsiz

Polars ile DuckDB karşılaştırması özellikle Python topluluğunda sık konuşulur. Polars Rust üzerine kurulu modern bir DataFrame kütüphanesidir; LazyFrame API’siyle sorgu planı oluşturur ve vektörize işler. Hız olarak DuckDB ile yarışır, hatta bazı senaryolarda öne geçer. Ancak Polars bir DataFrame API’sidir, SQL motorunun tüm özelliklerine sahip değildir; window function, recursive CTE, view, transaction, persistent storage gibi konular DuckDB’de daha olgundur. Ayrıca DuckDB Polars DataFrame’lerini doğrudan tablo gibi sorgulayabilir; iki aracı birlikte kullanmak yaygındır.

ClickHouse, DuckDB’nin “sunucu kuzeni” gibi düşünülebilir. Sütunlu, vektörize, ama dağıtık ve sunucu tabanlı. Petabayt ölçeğinde event tracking, log analytics, real-time dashboard senaryolarında ClickHouse standarttır. DuckDB’yi tercih etmenin sebebi: 1 TB altı veri, tek kullanıcı veya küçük takım, sunucu bakımından kaçınma. Druid, Pinot ve Trino karşılaştırması yüksek concurrency’li sunucu-tabanlı OLAP seçeneklerini ele alır; DuckDB GitHub deposu ise sürüm değişiklik notları ve performans iyileştirmelerini takip etmek için referans noktasıdır.

Local-First, Lakehouse ve MotherDuck

“Local-first” terimi, hesaplamanın bulut yerine kullanıcının makinesinde gerçekleşmesi anlamına gelir. DuckDB bu paradigmayı somutlaştırır. Veri ekibi tipik akışta önce S3’teki Parquet’leri Snowflake’e yükler, sonra SQL koşar, sonra Tableau’ya çıktı verir. DuckDB ile Parquet’i doğrudan dizüstüden sorgulayabilir, sonucu CSV/Excel olarak alabilir, tüm akış 5-10 dakikaya iner ve warehouse ücreti oluşmaz. Lakehouse mimarisinde DuckDB, Iceberg ve Delta Lake formatlarını okuyabildiği için Databricks/Snowflake tablolarını lokal bir client gibi sorgulayabilir; ana motoru bulutta tutup ad-hoc keşfi dizüstüde koşmak yaygın bir hibrit desendir. Lakehouse mimarisi rehberi bu yaklaşımın detaylarını anlatır.

Senaryo	Klasik (Warehouse)	DuckDB Local-First	Tasarruf
Ad-hoc keşif (1 saat/gün)	$200-500/ay warehouse	$0 (laptop)	%100
Aylık raporlama batch	$50-150/ay compute	$0 + cron + S3 fetch	%95+
ETL prototip geliştirme	Dev warehouse $100/ay	Local DuckDB	%100
Tek seferlik veri auditi	SF credit harcaması	S3’ten Parquet çek + sorgu	%90+
Notebook EDA	BigQuery slot	duckdb.sql() inline	%100

Local-first yaklaşımın sınırları açık olmalı: çoklu kullanıcı concurrent yazma, sürekli streaming ingestion, 24/7 uptime gerektiren prod sistemler, petabayt ölçeği veri ve sıkı RBAC senaryoları DuckDB için uygun değildir. Ancak veri ekibinin günlük işinin %60-80’i ad-hoc keşif, prototipleme ve orta ölçekli rapor üretmek olduğundan, DuckDB bu yükü sıfır marjinal maliyetle absorbe eder.

MotherDuck, DuckDB kurucu ekibinin (Jordan Tigani, eski BigQuery kurucu mühendisi) başlattığı yönetilen bulut hizmetidir. “Dual execution” konseptiyle çalışır: bazı sorgular bulutta koşar, bazıları dizüstüde; sistem optimal noktaya karar verir. ATTACH 'md:my_db'; tek komutuyla bağlanır, ücretlendirme veri boyutu + sorgu süresi üzerinden gider. 2026 başı itibarıyla enterprise paketinde row-level security, audit log ve SSO olgunlaştı. Modal, Coiled, AWS Lambda gibi serverless platformlarda DuckDB’yi koşturan örüntü (“DuckDB as compute”) da yaygındır; Lambda soğuk başlangıç 200-500 ms, sıcak çalışma 50-200 ms düzeyindedir. MotherDuck dokümantasyonu dual execution ayrıntılarını listeler.

• MotherDuck Free tier: 10 GB veri, sınırlı compute. Ne zaman seç: kişisel proje, POC.
• Standard tier: Daha geniş depo + share özelliği. Avantaj: ekip arasında tablo paylaşımı.
• Enterprise: SSO, RBAC, audit, custom region. Ne zaman seç: 20-200 kişilik veri ekipleri.
• Self-host: Yalnızca DuckDB ikili dosya + S3 + cron. Dezavantaj: share/yönetim manuel.

Gerçek Dünya Senaryoları ve Anti-Patterns

DuckDB’nin parladığı somut iş yüklerini sıralayalım. Veri keşfi: bir veri bilimci 30 GB Parquet’in şemasını ve örnek dağılımını anlamak için 5 dakika içinde sonuca ulaşır. Notebook tabanlı raporlama: Jupyter’da pandas yerine duckdb.sql() ile yazılan analizler 10-50 kat hızlı koşar, bellek kullanımı ise daha düşüktür. ML feature engineering: Polars veya pandas yerine SQL ile yazılan window function, group-by agregasyon adımları net ve sürdürülebilirdir. Veri kalitesi denetimi: Great Expectations veya Soda gibi araçlar yerine veya yanında DuckDB SQL ile null oranı, duplicate, ranged-check sorguları çalıştırılabilir.

Üretim senaryolarına dair üç örnek paylaşabilirim. Ömer Önal danışmanlık projelerinde bir e-ticaret müşterimiz için günlük raporlama pipeline’ını AWS RDS PostgreSQL’den DuckDB + S3’e taşıdık; aylık maliyet 1200 USD’den 80 USD’ye düştü, sorgu süreleri 5-15 dakikadan 20-60 saniyeye indi. Bir SaaS analitik müşterisinde, müşteri-bazlı raporları sunucu-tarafında DuckDB ile generate ederek Snowflake credit tüketimini %40 azalttık. Bir medya şirketinde, GA4 BigQuery export’larını gece DuckDB ile pre-aggregate edip Looker Studio’ya beslemek, BQ slot maliyetini %60 düşürdü.

Anti-pattern listesi de eşit derecede önemlidir. DuckDB’yi şu durumlarda kullanmayın: high-concurrency OLTP API backend (PostgreSQL kullanın), 5+ kişi eş zamanlı yazma yapacak (warehouse veya OLTP DB), 24/7 streaming ingest (Kafka + ClickHouse veya Flink/Kafka stream processing stack’i), veri yönetişimi ve KVKK gereği sıkı RBAC ve audit log, petabayt ölçeği OLAP (Snowflake/BigQuery/Trino). DuckDB ne yapmak istediğinizi sade tutar; karmaşa eklediğinizde alet sınırına çarparsınız.

Senaryo	Uygunluk	Alternatif
Lokal Parquet ad-hoc analiz	Mükemmel	—
Notebook EDA	Mükemmel	Polars (DataFrame)
Aylık batch rapor	İyi	Airflow + warehouse
Real-time streaming dashboard	Kötü	ClickHouse, Druid, Pinot
OLTP API backend	Çok kötü	PostgreSQL, MySQL
50+ kullanıcı concurrent BI	Kötü	Snowflake, BigQuery
ML feature store query	İyi (≤1 TB)	BigQuery, Redshift
Embedded edge analytics	Mükemmel	—
WASM tarayıcı analitik	Mükemmel	—

Üretim Operasyonu ve Ekosistem

DuckDB’yi üretim pipeline’ında kullanırken dikkat edilecek temel konular sınırlı sayıdadır. Tek yazıcı modeli, bellek yönetimi, güvenlik ve sürüm uyumluluğu başlıkları hızlıca özetlenebilir:

1. Tek yazıcı kilidi: Aynı .duckdb dosyasını iki süreç eş zamanlı yazma için açamaz; read-only mod ile çoklu okuyucu mümkündür. Ne zaman önemli: shared writer senaryosunda orchestration katmanı gerekir.
2. Bellek limiti: SET memory_limit = '8GB'; ile sınırlanır; aşıldığında out-of-core spilling devreye girer. Avantaj: RAM tükenmez. Dezavantaj: spilling sorguyu yavaşlatır.
3. Transaction modeli: ACID + MVCC tek yazıcı; yüksek frekanslı küçük insert yerine batch insert (1000+ satır) tercih edin.
4. Güvenlik: Embedded mimari, OS kullanıcı yetkilerini miras alır. DuckDB güvenlik politikası multi-tenant senaryolarda WASM sandbox veya MotherDuck izolasyonu önerir.
5. Sürüm uyumluluğu: 1.0 sonrası dosya format kararlılığı garanti. Üretim için 1.x kararlı sürümlerden yararlanın; CHECKPOINT ile periyodik flush ve snapshot backup standarttır.

Ekosistem tarafında DuckDB tek başına değildir. Orchestration için Dagster, Mage, Airflow; analytics engineering için dbt-duckdb adapter; ELT için dlt ve Meltano; notebook için Hex, Mode, Deepnote; dashboard için Streamlit ve Evidence.dev; BI için ODBC üzerinden Tableau ve Power BI bağlanır. ibis ve sqlalchemy dialect’leri sayesinde aynı kodu Snowflake’e taşımak görece kolaydır. vss eklentisi HNSW indeksiyle 1-10 milyon vektörlük embedding koleksiyonları için Pinecone/Weaviate alternatifi sunar; RAG prototipleri için sıfır-setup avantajı belirgindir.

Sıkça Sorulan Sorular

Sonuç

DuckDB, analitik dünyasının “küçük olan güzeldir” akımını somutlaştıran araçtır. Tek bir ikili dosya, sıfır kurulum, modern donanımda dakikalar yerine saniyelerde sonuç. 2026’da veri ekiplerinin alet kemerinde olmaması neredeyse imkânsız; warehouse’ları tamamen ikame etmese de günlük ad-hoc iş yükünün önemli kısmını absorbe ediyor ve operasyonel maliyetleri kayda değer biçimde düşürüyor.

Karar çerçevesi netleştirilebilir. Şu üç soruyu sorun: Verim ne kadar (1 TB altı mı)? Concurrency düşük mü (10 altı kullanıcı)? Iş yükü ad-hoc keşif veya batch rapor mu? Üç yanıt evet ise DuckDB ana motor olabilir. En az biri hayır ise DuckDB yardımcı/tamamlayıcı rolü oynar, ana motor warehouse veya OLAP cluster olur. Hibrit kullanımdan kaçınmak için bir neden yoktur; lakehouse içindeki tabloyu Databricks ile yönetip, ad-hoc analizi DuckDB ile koşmak yaygın ve sağlıklı bir desendir.

Veri yığınınızı sadeleştirmek, warehouse maliyetlerini düşürmek veya local-first bir analitik kültürü kurmak istiyorsanız DuckDB temelli bir mimari tasarlamak doğru adım olabilir. Bu tip dönüşüm projelerinde stack seçimi, taşıma planı ve operasyonel disiplini birlikte konuşmak için iletişim sayfası üzerinden bağlantıya geçebilirsiniz.