DuckDB makes it pretty easy to query across Postgres and Parquet files in S3.
The query itself is not the hard part anymore.
The mess starts when the same query needs to be reused:
<ul>
<li>saved DB connections</li>
<li>S3 paths</li>
<li>schema checks</li>
<li>aliases</li>
<li>result exports</li>
<li>reruns</li>
<li>sometimes using the result as input for load or migration</li>
</ul>
That is the part people often hide in a Python script, Makefile, notebook, or some “temporary” glue code that quietly becomes important.
The article came from the workflow we built around DuckDB in DBConvert Streams.
DuckDB is the engine.
The missing layer is often the repeatable workspace around it.
<a href="https://streams.dbconvert.com/blog/duckdb-cross-source-sql-workflow/" target="_blank" rel="noopener nofollow">https://streams.dbconvert.com/blog/duckdb-cross-source-sql-workflow/</a>

Your go-to source for the latest in database technology, trends, and tips. Covering Postgres, MySQL, Kafka, Data Warehouses, and more. 

Database Daily

DuckDB has largely solved the query engine problem, making cross-source queries across Postgres and Parquet files in S3 straightforward. The real challenge lies in the repeatable workflow around those queries: managing saved connections, S3 paths, schema checks, aliases, result exports, and reruns. This glue logic often ends up scattered across Python scripts, Makefiles, or notebooks. The post introduces a structured workspace layer built around DuckDB in DBConvert Streams to address this gap.

DuckDB solved the query engine. The workflow around it is still messy