When would you attach DuckDB directly to a PostgreSQL database instead of exporting data first?

Exporting data from PostgreSQL before analyzing it, dumping to CSV, loading into another tool, adds a manual step, introduces staleness (the exported snapshot immediately starts drifting from the live database), and requires managing that export/import pipeline as its own piece of infrastructure. Attaching DuckDB directly to PostgreSQL via the postgres extension skips all of that for cases where it's a good fit.

This direct-attach approach is the right call for ad hoc or exploratory analysis where querying live, current data matters more than raw scan performance, or where the actual amount of data being pulled from Postgres per query is modest, since every row DuckDB reads from an attached Postgres table still has to come across that connection using Postgres's own row-oriented access path, without benefiting from DuckDB's columnar pruning the way a native Parquet file would.

For genuinely large-scale, repeated analytical workloads against the same Postgres data, actually exporting to a columnar format (Parquet) periodically, or maintaining a proper analytical replica, tends to be the better long-term approach, since it avoids repeatedly paying Postgres's row-oriented read cost for every analytical query and lets DuckDB's columnar strengths actually apply to the data being scanned.