July 8, 2026
Summary: in this tutorial, you will learn how to accelerate analytics with pg_duckdb in PostgreSQL.
Table of Contents
Core Viewpoints & Background
- Current Pain Points: PostgreSQL is the world’s most trusted open-source relational database, excelling in OLTP (Online Transaction Processing). However, it struggles with large aggregate queries for OLAP (Online Analytical Processing). Traditionally, users have to export data via ETL pipelines to a dedicated data warehouse for efficient analytics.
- The Solution:
pg_duckdbis a PostgreSQL extension that embeds DuckDB’s columnar, vectorized analytical engine directly into your PostgreSQL database. - Core Value: Users don’t need to switch databases or migrate/sync data. By simply enabling the extension, a single database instance can deliver powerful OLTP and OLAP capabilities simultaneously.

Deep Dive into Core Principles: PostgreSQL vs. DuckDB
Due to their distinct architectural designs, both engines excel in different scenarios. Here is a clear comparison of their underlying features:
| Comparison Dimension | PostgreSQL (OLTP Champion) | DuckDB (OLAP Powerhouse) |
|---|---|---|
| Data Storage | Row-oriented: Reads row by row. Even if an analytical query only needs a few columns, it reads entire rows, leading to wasted I/O resources. | Columnar: Reads compressed data blocks by column, significantly saving I/O resources and accelerating analysis. |
| Execution Model | Volcano Iterator: Processes data one row at a time, leaving modern CPU caches and SIMD instructions largely unused. | Vectorized Execution: Processes data in batches (thousands of values at a time) for blazing-fast execution. |
| Concurrency & Parallelism | Optimized for high-concurrency, multi-user scenarios via MVCC (many small transactions per second); parallel query capabilities are bounded. | Optimized for single, large, and complex queries; automatic parallelism utilizing all available CPU cores. |
| External Data Sources | Defaults to reading internal database tables. | Native data lake support. Directly reads Parquet, CSV, JSON, and Iceberg files—whether on local disks or object storage (like S3 Object Storage)—without loading them. |
| Architecture | Traditional Client-Server (C/S) architecture. | In-process embedded database, no standalone server/daemon, and zero-configuration startup. |

How pg_duckdb Works
The power of pg_duckdb lies in its transparency to the application layer. Clients don’t need to change connection methods, wire protocols, or SQL statements:
- Query Interception: After the Postgres parser generates the parse tree,
pg_duckdbhooks in and checks if the query is an analytical one that it can handle. - Takeover & Execution: If suitable, it builds a DuckDB execution plan, hands it to DuckDB’s vectorized engine for lightning-fast processing, and returns the results to the client through Postgres.
- Transparent Fallback (Automatic Fallback): If a query is unsupported (e.g., an
INSERTor features DuckDB doesn’t currently support), the extension quietly hands it back to the native Postgres planner. This ensures zero application breakage and requires no code modification.

The Three “Superpowers” of pg_duckdb
There are three key use cases of this extension on PostgreSQL:
1. Accelerate Existing Tables with Zero Code Changes
- Simply enable the parameter by running
set duckdb.force_execution = on;. - Existing analytical queries (e.g.,
GROUP BYaggregations) on Postgres tables are automatically routed to the DuckDB engine. - Test Results: In the TPC-H benchmark demo, query speeds improved by 2.4x to nearly 7x compared to the native engine on the exact same dataset.
2. Read and Write Directly to Cloud Object Storage

- Say goodbye to ETL pipelines; there is no need to ingest massive datasets into the database.
- Using simple SQL functions (like
read_parquet), you can directly query historical Parquet files stored in S3 Object Storage, and even write analytical results back to the S3 Object Storage.
3. Hybrid Analytics — The Most Powerful Feature

- Scenario: Within a single SQL query, you can
JOINlive operational data in Postgres (e.g., an active portfolio watchlist table) directly with external files in S3 Object Storage (e.g., massive historical stock trading Parquet files). - Advantage: Seamlessly blends “hot” operational data with “cold” historical archives in a single engine without intermediate extraction steps or data duplication.
Key Takeaways
- One Database, Two Engines: Combines ACID transactional safety (Postgres) with lightning-fast analytical performance (DuckDB) in the same managed server.
- Zero Data Movement: Query the Data Lake or object storage directly with SQL without moving data through external pipelines.
- Unified Hybrid Analytics: Join live relational operational data with external large files in a single SQL statement.
- Same SQL, Faster Answers: No need to learn a new system or change existing query code; simply swap the underlying compute engine for a massive performance boost.
Reference
pg_duckdb in Action: Accelerating Analytics on Azure Database for PostgreSQL