Skip to main content
hc
Submit
toolsSource-backed
DuckDB logo

DuckDB

MIT-licensed embedded analytical SQL database for local OLAP workloads, data files, notebooks, Python and R clients, extensions, and single-file analytics workflows.

by DuckDB Foundation · submitted by oktofeesh1·added 2026-06-04·
CLI
HarnessCLI
Review first — review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Canonical URL
https://heyclau.de/entry/tools/duckdb
Source URLs
https://duckdb.org/docs/current/clients/overview, https://github.com/duckdb/duckdb, https://duckdb.org/
Brand
DuckDB
Brand domain
duckdb.org
Brand asset source
brandfetch
Safety notes
DuckDB SQL should be treated like executable code because queries can read and write files, access network resources through extensions, load extensions, consume system resources, and mutate attached databases., Applications that accept user-controlled SQL, file paths, table names, filter expressions, or data-source settings need sandboxing and allowlists rather than passing those values directly into DuckDB operations., Extensions run with the same privileges as the DuckDB process, and community extensions should only be installed from trusted sources after reviewing their maintenance and distribution path., Statements such as `ATTACH`, `COPY`, `EXPORT DATABASE`, `CREATE SECRET`, `INSERT`, `UPDATE`, and `DELETE` can change local files, databases, or connected services when permissions allow it., Analytical queries can use substantial CPU, memory, temporary disk, and object-store bandwidth, so shared automations should configure memory, thread, timeout, temp-directory, and retry expectations., Persistent database files and write-ahead logs need backups, file permissions, and recovery procedures before DuckDB is used for durable or production-adjacent analytical state.
Privacy notes
DuckDB workflows can process local files, database files, notebooks, query text, table names, column names, object-store paths, data-frame contents, connection strings, secrets, extensions, and generated result sets., The files-created docs describe global files such as `~/.duckdb_history`, extension directories, and stored persistent secrets, so users should avoid typing credentials or sensitive data into ad hoc SQL history., Persistent secrets are stored under DuckDB's configured secret directory, and `duckdb_secrets()` redacts sensitive fields by default; enabling unredacted secret output is unsafe with untrusted SQL., On-disk databases can create database files, write-ahead logs, and temporary directories next to the database file or working directory, depending on connection mode and configuration., HTTP, S3, and other external-data workflows can expose object-store identifiers, paths, credentials, request metadata, and result data to the connected service and any configured logs or monitoring.
Author
DuckDB Foundation
Submitted by
oktofeesh1
Claim status
unclaimed
Last verified
2026-06-04

Decision playbook

Review trust signals before you adopt

Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.

Compare context
Selected

0

Current score

78

Baseline

—

Delta

No baseline selected

No major trust-signal divergence detected in the current selection.

Source and provenance checks

Complete

Confirm ownership and provenance before trusting install instructions.

  • Source link availableRequired

    Open the canonical repository and verify ownership.

    Done

  • Source provenance statusRequired

    Marked as source-backed.

    Done

  • Metadata reviewed

    Registry metadata indicates a reviewed listing.

    Done

Safety and privacy checks

Complete

Validate risk disclosures before installation or API wiring.

  • Safety notes presentRequired

    Review the listed safety guidance before running commands.

    Done

  • Privacy notes presentRequired

    Review data handling notes before connecting accounts or secrets.

    Done

  • Trust level risk gateRequired

    Trust level does not block evaluation.

    Done

Package and install checks

Needs review

Check package metadata and artifact integrity signals.

  • Install payload available

    Install or copy payload is available for review.

    Done

  • Package verification flag

    No package verification flag provided.

    Pending

  • Checksum metadata

    No checksum provided for downloaded artifact.

    Pending

Compare-driven decision checks

Needs review

Use compare context to validate trade-offs before adoption.

  • Compare tray has multiple entries

    Add at least one more entry to compare trust differences.

    Pending

  • Baseline comparison available

    No baseline peer selected yet.

    Pending

  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

Copy & paste

Copy-ready — paste the snippet to get started.

Install command

Not provided

Config snippet

Not provided

Copy snippet

Provided

Prerequisites

5 to clear

Platforms

1 listed

Install type

Copy & paste

Adoption plan

Balanced adoption plan

Current risk score 16/100. Use staged verification before broader rollout.

Risk 16

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done

  • Confirm metadata review state

    Listing has review metadata.

    Done

  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done

  • Review privacy notesRequired

    Privacy notes are present.

    Done

  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending

  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending

  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Required evidence gates are covered (5/6 signals complete).

Risk 15

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Present

Review metadata is present.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required evidence gates are covered for this preset.

Decision timeline

Decision timeline · balanced

5/6 steps complete with no blocking gaps for this preset.

Risk 14

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is available.

Done

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

No required blockers for this timeline preset.

Prerequisite readiness

Prerequisite readiness

5 prerequisites to line up before setup. Have accounts and credentials ready first.

0/5 ready
Account & credentials1Install & runtime1Configuration2General1

Safety & privacy surface

Safety & privacy surface

6 safety and 5 privacy notes across 4 risk areas. Review closely: credentials & tokens, permissions & scopes, network access.

4 areas
  • SafetyNetwork accessDuckDB SQL should be treated like executable code because queries can read and write files, access network resources through extensions, load extensions, consume system resources, and mutate attached databases.
  • SafetyLocal filesApplications that accept user-controlled SQL, file paths, table names, filter expressions, or data-source settings need sandboxing and allowlists rather than passing those values directly into DuckDB operations.
  • SafetyLocal filesExtensions run with the same privileges as the DuckDB process, and community extensions should only be installed from trusted sources after reviewing their maintenance and distribution path.
  • SafetyCredentials & tokensStatements such as `ATTACH`, `COPY`, `EXPORT DATABASE`, `CREATE SECRET`, `INSERT`, `UPDATE`, and `DELETE` can change local files, databases, or connected services when permissions allow it.
  • SafetyLocal filesAnalytical queries can use substantial CPU, memory, temporary disk, and object-store bandwidth, so shared automations should configure memory, thread, timeout, temp-directory, and retry expectations.
  • SafetyPermissions & scopesPersistent database files and write-ahead logs need backups, file permissions, and recovery procedures before DuckDB is used for durable or production-adjacent analytical state.
  • PrivacyCredentials & tokensDuckDB workflows can process local files, database files, notebooks, query text, table names, column names, object-store paths, data-frame contents, connection strings, secrets, extensions, and generated result sets.
  • PrivacyCredentials & tokensThe files-created docs describe global files such as `~/.duckdb_history`, extension directories, and stored persistent secrets, so users should avoid typing credentials or sensitive data into ad hoc SQL history.
  • PrivacyCredentials & tokensPersistent secrets are stored under DuckDB's configured secret directory, and `duckdb_secrets()` redacts sensitive fields by default; enabling unredacted secret output is unsafe with untrusted SQL.
  • PrivacyLocal filesOn-disk databases can create database files, write-ahead logs, and temporary directories next to the database file or working directory, depending on connection mode and configuration.
  • PrivacyCredentials & tokensHTTP, S3, and other external-data workflows can expose object-store identifiers, paths, credentials, request metadata, and result data to the connected service and any configured logs or monitoring.

Disclosure: editorial

Safety notes

  • DuckDB SQL should be treated like executable code because queries can read and write files, access network resources through extensions, load extensions, consume system resources, and mutate attached databases.
  • Applications that accept user-controlled SQL, file paths, table names, filter expressions, or data-source settings need sandboxing and allowlists rather than passing those values directly into DuckDB operations.
  • Extensions run with the same privileges as the DuckDB process, and community extensions should only be installed from trusted sources after reviewing their maintenance and distribution path.
  • Statements such as `ATTACH`, `COPY`, `EXPORT DATABASE`, `CREATE SECRET`, `INSERT`, `UPDATE`, and `DELETE` can change local files, databases, or connected services when permissions allow it.
  • Analytical queries can use substantial CPU, memory, temporary disk, and object-store bandwidth, so shared automations should configure memory, thread, timeout, temp-directory, and retry expectations.
  • Persistent database files and write-ahead logs need backups, file permissions, and recovery procedures before DuckDB is used for durable or production-adjacent analytical state.

Privacy notes

  • DuckDB workflows can process local files, database files, notebooks, query text, table names, column names, object-store paths, data-frame contents, connection strings, secrets, extensions, and generated result sets.
  • The files-created docs describe global files such as `~/.duckdb_history`, extension directories, and stored persistent secrets, so users should avoid typing credentials or sensitive data into ad hoc SQL history.
  • Persistent secrets are stored under DuckDB's configured secret directory, and `duckdb_secrets()` redacts sensitive fields by default; enabling unredacted secret output is unsafe with untrusted SQL.
  • On-disk databases can create database files, write-ahead logs, and temporary directories next to the database file or working directory, depending on connection mode and configuration.
  • HTTP, S3, and other external-data workflows can expose object-store identifiers, paths, credentials, request metadata, and result data to the connected service and any configured logs or monitoring.

Prerequisites

  • DuckDB distribution and client choice for the workflow, such as the CLI, Python, R, Java, Node.js, C or C++ APIs, Rust, ODBC, JDBC, or WebAssembly.
  • Data access plan for local DuckDB files, in-memory databases, CSV, Parquet, JSON, Arrow, pandas, R data frames, lakehouse formats, HTTP sources, S3-compatible storage, and mounted working directories.
  • Version, extension, and file-format compatibility policy for shared notebooks, CI jobs, production scripts, persisted database files, and generated analytical artifacts.
  • Resource controls for memory, threads, temporary directories, maximum temporary directory size, checkpointing, write-ahead logs, and long-running analytical queries.
  • Security model for trusted SQL authors, untrusted input, file-system access, external network access, extension installation, object-store credentials, secrets, and generated query output.

Schema details

Install type
copy
Troubleshooting
No
Source repository stats
Scope
Source repo
Tool listing metadata
Pricing
open-source
Disclosure
editorial
Application category
DeveloperApplication
Operating system
macOS, Windows, Linux, WebAssembly
Full copyable content
## Editorial notes

DuckDB is useful when Claude-adjacent teams need fast local analytics over data files, notebooks, evaluation outputs, logs, parquet datasets, ad hoc CSV exports, feature-engineering experiments, and lightweight analytical databases without running a separate database server. It gives agents and developers a compact SQL engine for inspecting data, joining files, validating transformations, and producing repeatable analytical artifacts close to the workspace.

This is distinct from dbt Core, Apache Airflow, and Dagster. dbt Core structures and runs warehouse transformation projects. Airflow schedules workflow DAGs. Dagster orchestrates software-defined assets and operational metadata. DuckDB is the embedded analytical database engine that can execute SQL over files, data frames, extensions, and local database files inside scripts, notebooks, tools, and applications.

## Source notes

- The official repository describes DuckDB as a high-performance analytical database system with a rich SQL dialect, a standalone CLI, and clients for Python, R, Java, WebAssembly, and other environments.
- The repository documents simple direct querying of CSV and Parquet files by referencing file names in SQL.
- The installation page lists current stable and LTS installation options, including binaries and packages for major programming languages and platforms.
- The official why page says DuckDB is an embedded in-process relational DBMS, does not require separate server software, and targets analytical query workloads.
- The why page describes portability across major operating systems and CPU architectures, APIs for C, C++, Go, Python, R, Rust, Java, Node.js, and other languages, and deep Python and R integrations.
- The why page says DuckDB uses a columnar-vectorized query execution engine for OLAP workloads and is released under the MIT License.
- The DuckDB Foundation page says the independent non-profit DuckDB Foundation safeguards long-term maintenance and development and holds most project intellectual property.
- The client overview docs list CLI, Python, R, Java, Node.js, ODBC, Rust, WebAssembly, Swift, Julia, Dart, and related client APIs.
- The data import docs describe efficient loading and querying for CSV, Parquet, and JSON files.
- The configuration docs describe settings for memory limits, worker threads, external access, disabled file systems, extension directories, home directories, secret directories, temporary directories, and maximum temporary directory size.
- The extension docs describe built-in, core, and community extensions, explicit `INSTALL` and `LOAD` statements, autoloading, local extension directories, and signed community extensions.
- The securing DuckDB docs warn to treat SQL like Bash or Python code, explain risks from untrusted SQL and non-SQL input, and describe restrictions for file access, external access, extensions, and secrets.
- The files-created docs describe `~/.duckdb_history`, `~/.duckdb/extensions`, `~/.duckdb/stored_secrets`, database files, temporary directories, and write-ahead logs.
- The repository is `duckdb/duckdb`, is MIT licensed, and is active.

## Duplicate check

Checked current `content/tools/`, `content/mcp/`, agents, hooks, rules, skills, commands, guides, collections, open pull requests, live issue state, and repository-wide content for `DuckDB`, `duckdb`, `duckdb/duckdb`, `github.com/duckdb/duckdb`, `duckdb.org`, `duckdb.foundation`, `embedded OLAP`, and `analytical SQL`. No dedicated DuckDB tools entry, source URL duplicate, target file, issue duplicate, or open duplicate PR was found.

## Disclosure

Editorial listing. No paid placement or affiliate link is used. DuckDB is MIT-licensed open-source software; DuckDB Labs services, cloud platforms, object stores, notebooks, BI tools, extensions, deployment environments, and downstream systems may have separate licenses, billing, terms, privacy obligations, and access controls.

About this resource

Editorial notes

DuckDB is useful when Claude-adjacent teams need fast local analytics over data files, notebooks, evaluation outputs, logs, parquet datasets, ad hoc CSV exports, feature-engineering experiments, and lightweight analytical databases without running a separate database server. It gives agents and developers a compact SQL engine for inspecting data, joining files, validating transformations, and producing repeatable analytical artifacts close to the workspace.

This is distinct from dbt Core, Apache Airflow, and Dagster. dbt Core structures and runs warehouse transformation projects. Airflow schedules workflow DAGs. Dagster orchestrates software-defined assets and operational metadata. DuckDB is the embedded analytical database engine that can execute SQL over files, data frames, extensions, and local database files inside scripts, notebooks, tools, and applications.

Source notes

  • The official repository describes DuckDB as a high-performance analytical database system with a rich SQL dialect, a standalone CLI, and clients for Python, R, Java, WebAssembly, and other environments.
  • The repository documents simple direct querying of CSV and Parquet files by referencing file names in SQL.
  • The installation page lists current stable and LTS installation options, including binaries and packages for major programming languages and platforms.
  • The official why page says DuckDB is an embedded in-process relational DBMS, does not require separate server software, and targets analytical query workloads.
  • The why page describes portability across major operating systems and CPU architectures, APIs for C, C++, Go, Python, R, Rust, Java, Node.js, and other languages, and deep Python and R integrations.
  • The why page says DuckDB uses a columnar-vectorized query execution engine for OLAP workloads and is released under the MIT License.
  • The DuckDB Foundation page says the independent non-profit DuckDB Foundation safeguards long-term maintenance and development and holds most project intellectual property.
  • The client overview docs list CLI, Python, R, Java, Node.js, ODBC, Rust, WebAssembly, Swift, Julia, Dart, and related client APIs.
  • The data import docs describe efficient loading and querying for CSV, Parquet, and JSON files.
  • The configuration docs describe settings for memory limits, worker threads, external access, disabled file systems, extension directories, home directories, secret directories, temporary directories, and maximum temporary directory size.
  • The extension docs describe built-in, core, and community extensions, explicit INSTALL and LOAD statements, autoloading, local extension directories, and signed community extensions.
  • The securing DuckDB docs warn to treat SQL like Bash or Python code, explain risks from untrusted SQL and non-SQL input, and describe restrictions for file access, external access, extensions, and secrets.
  • The files-created docs describe ~/.duckdb_history, ~/.duckdb/extensions, ~/.duckdb/stored_secrets, database files, temporary directories, and write-ahead logs.
  • The repository is duckdb/duckdb, is MIT licensed, and is active.

Duplicate check

Checked current content/tools/, content/mcp/, agents, hooks, rules, skills, commands, guides, collections, open pull requests, live issue state, and repository-wide content for DuckDB, duckdb, duckdb/duckdb, github.com/duckdb/duckdb, duckdb.org, duckdb.foundation, embedded OLAP, and analytical SQL. No dedicated DuckDB tools entry, source URL duplicate, target file, issue duplicate, or open duplicate PR was found.

Disclosure

Editorial listing. No paid placement or affiliate link is used. DuckDB is MIT-licensed open-source software; DuckDB Labs services, cloud platforms, object stores, notebooks, BI tools, extensions, deployment environments, and downstream systems may have separate licenses, billing, terms, privacy obligations, and access controls.

#analytics-database#sql#data-engineering

Source citations

Add this badge to your README

Show that DuckDB is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/tools/duckdb.svg)](https://heyclau.de/entry/tools/duckdb)

How it compares

DuckDB side by side with its closest alternative on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

Field
DuckDB logoDuckDB

MIT-licensed embedded analytical SQL database for local OLAP workloads, data files, notebooks, Python and R clients, extensions, and single-file analytics workflows.

Open dossier
dbt Core logodbt Core

Apache-2.0 dbt engine for transforming warehouse data with SQL models, Jinja, YAML configs, tests, documentation, lineage, metadata, and build artifacts.

Open dossier
Next steps
Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing
Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing
Trust
Review statusReviewedMaintainer reviewedReviewedMaintainer reviewed
Package trustPackage not verifiedPackage not verified
Source provenanceSource-backedSource-backed
Submitteroktofeesh1oktofeesh1
Install riskReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
BrandDuckDB logoDuckDBdbt Core logodbt Core
Categorytoolstools
SourceSource-backedSource-backed
AuthorDuckDB Foundationdbt Labs
Added2026-06-042026-06-04
Platforms
CLI
CLI
Harness
CLI
CLI
Source repo——
Safety notes✓DuckDB SQL should be treated like executable code because queries can read and write files, access network resources through extensions, load extensions, consume system resources, and mutate attached databases. Applications that accept user-controlled SQL, file paths, table names, filter expressions, or data-source settings need sandboxing and allowlists rather than passing those values directly into DuckDB operations. Extensions run with the same privileges as the DuckDB process, and community extensions should only be installed from trusted sources after reviewing their maintenance and distribution path. Statements such as `ATTACH`, `COPY`, `EXPORT DATABASE`, `CREATE SECRET`, `INSERT`, `UPDATE`, and `DELETE` can change local files, databases, or connected services when permissions allow it. Analytical queries can use substantial CPU, memory, temporary disk, and object-store bandwidth, so shared automations should configure memory, thread, timeout, temp-directory, and retry expectations. Persistent database files and write-ahead logs need backups, file permissions, and recovery procedures before DuckDB is used for durable or production-adjacent analytical state.✓dbt runs transformation SQL against a data platform and can create, replace, or mutate warehouse objects, so development and production targets should be separated and permissioned carefully. The current `dbt-labs/dbt-core` README warns that `main` hosts dbt Core v2.0 alpha, that behavior, APIs, and on-disk formats may change, and that dbt Core v1 development has moved to `1.latest`. Version, adapter, package, and artifact compatibility should be pinned and tested before upgrading shared projects or production jobs. Model tests, contracts, lineage, and documentation improve confidence, but they do not replace data review, access controls, warehouse governance, freshness checks, or incident response. Threads, full refreshes, incremental logic, and CI jobs can consume warehouse budget or lock shared resources; teams should set concurrency, timeout, and rollback expectations before broad automation. Profile files and environment variables can contain sensitive warehouse credentials, so `profiles.yml` should stay out of git, logs, generated docs, screenshots, and shared support artifacts.
Privacy notes✓DuckDB workflows can process local files, database files, notebooks, query text, table names, column names, object-store paths, data-frame contents, connection strings, secrets, extensions, and generated result sets. The files-created docs describe global files such as `~/.duckdb_history`, extension directories, and stored persistent secrets, so users should avoid typing credentials or sensitive data into ad hoc SQL history. Persistent secrets are stored under DuckDB's configured secret directory, and `duckdb_secrets()` redacts sensitive fields by default; enabling unredacted secret output is unsafe with untrusted SQL. On-disk databases can create database files, write-ahead logs, and temporary directories next to the database file or working directory, depending on connection mode and configuration. HTTP, S3, and other external-data workflows can expose object-store identifiers, paths, credentials, request metadata, and result data to the connected service and any configured logs or monitoring.✓dbt workflows can process SQL models, Jinja macros, YAML configs, sources, tests, seeds, snapshots, metrics, exposures, connection profiles, warehouse relation names, logs, and generated artifacts. Command output and `logs/dbt.log` can include invocation arguments, runtime context, thread names, node metadata, warehouse relation identifiers, errors, and other debugging details. dbt artifacts are written to the project's `target/` directory by default and may include manifests, run results, catalogs, source freshness output, semantic manifests, invocation IDs, adapter types, project metadata, and selected environment metadata. The artifacts docs say environment variables prefixed with `DBT_ENV_CUSTOM_ENV_` can be included in artifact metadata, so teams should avoid placing secrets in those variables. The usage-stats docs say dbt telemetry is enabled by default and does not track credentials, raw model contents, or model names; dbt Core users can opt out by setting `send_anonymous_usage_stats` to false or `DO_NOT_TRACK=1`.
Prerequisites
  • DuckDB distribution and client choice for the workflow, such as the CLI, Python, R, Java, Node.js, C or C++ APIs, Rust, ODBC, JDBC, or WebAssembly.
  • Data access plan for local DuckDB files, in-memory databases, CSV, Parquet, JSON, Arrow, pandas, R data frames, lakehouse formats, HTTP sources, S3-compatible storage, and mounted working directories.
  • Version, extension, and file-format compatibility policy for shared notebooks, CI jobs, production scripts, persisted database files, and generated analytical artifacts.
  • Resource controls for memory, threads, temporary directories, maximum temporary directory size, checkpointing, write-ahead logs, and long-running analytical queries.
  • Choice of dbt Core version and engine path, including dbt Core v1 on the `1.latest` branch or dbt Core v2 alpha on `main` as the Rust-based Fusion foundation.
  • Supported adapter or driver for the selected data platform, warehouse credentials, target schemas, profiles configuration, and environment-specific dev, staging, and production targets.
  • dbt project structure for SQL models, Jinja, YAML configs, sources, seeds, snapshots, tests, documentation, exposures, metrics, macros, packages, and model contracts.
  • Warehouse permission model for creating, replacing, and reading relations, plus cost controls for threads, incremental models, full refreshes, CI builds, and scheduled jobs.
Install——
Config——
Citations
ClaimUnclaimedUnclaimed
Open in the interactive comparison tool

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.