Skip to content

feat(duckdb): Amazon S3 / Object Storage data source (DTL-1808)#2785

Draft
m1n0 wants to merge 2 commits into
mainfrom
DTL-1808-object-storage-source
Draft

feat(duckdb): Amazon S3 / Object Storage data source (DTL-1808)#2785
m1n0 wants to merge 2 commits into
mainfrom
DTL-1808-object-storage-source

Conversation

@m1n0

@m1n0 m1n0 commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Amazon S3 / Object Storage data source (DTL-1808)

Adds S3 / object-storage support to the DuckDB engine plugin so files in S3 (Parquet/CSV/JSON) can be scanned directly, before ingestion into a warehouse.

What's in it

  • New connection.object_storage block on the DuckDB data source: provider: s3, region, polymorphic auth (assume-role or access-key), and datasets (each a name + S3 path/glob + format).
  • On connect: INSTALL/LOAD httpfs, build S3 credentials (STS AssumeRole via boto3, or static access-key), CREATE SECRET, and one CREATE VIEW per dataset over read_parquet / read_csv_auto / read_json_auto (globs supported).
  • Discovery includes VIEWs for object-storage sources (scoped so local-file DuckDB behaviour is unchanged).
  • Fixes the file-mode configuration-dict-ignored gap.

Tests

41 passing in soda-duckdb — config parse (both auth modes), view creation over local files, assume-role (STS mocked), discovery, error cases.

Runtime note

The runner image must have the DuckDB httpfs extension available (egress at connect time, or pre-bundled offline).

Part of the cross-repo object-storage feature (soda, soda-contract-launcher, docs). Ticket: DTL-1808.

m1n0 and others added 2 commits July 7, 2026 15:11
Add an `object_storage` block to the DuckDB connection config so a
`type: duckdb` source can point at Amazon S3. Its presence marks the
source as S3-backed: on connect the engine installs/loads httpfs, resolves
AWS credentials (static access-key or STS AssumeRole, with optional
ExternalId), registers a DuckDB S3 secret (CREATE SECRET, with a SET
s3_* pragma fallback for DuckDB < 0.10), and exposes each configured
dataset (prefix+glob) as a lazy view over read_parquet / read_csv_auto /
read_json_auto. Views appear in information_schema.tables so the existing
discovery/profiling/scan pipeline reuses them unchanged.

Also fix the file-extension connection branch, which silently ignored the
`configuration` dict: it now applies the settings via SET (the `:default:`
connection cannot accept a config= kwarg).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Object-storage (S3) datasets are exposed as DuckDB VIEWs, but the default
discovery/metadata path (discover_qualified_objects with object_types=None)
enumerates TABLEs only, so real profiling/discovery found nothing for an S3
source. DuckDBDataSourceImpl.discover_qualified_objects now includes VIEWs in
the default object types when the source is an object-storage source. Standard
and local-file DuckDB sources (which materialize TABLEs) keep the TABLE-only
default, so their behavior is unchanged.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@sonarqubecloud

sonarqubecloud Bot commented Jul 8, 2026

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant