PostgreSQL Tutorial: Accelerating Analytics with pg_duckdb

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_duckdb is 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.

image

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.

image

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:

  1. Query Interception: After the Postgres parser generates the parse tree, pg_duckdb hooks in and checks if the query is an analytical one that it can handle.
  2. 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.
  3. Transparent Fallback (Automatic Fallback): If a query is unsupported (e.g., an INSERT or 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.

image

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 BY aggregations) 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

image

  • 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

image

  • Scenario: Within a single SQL query, you can JOIN live 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

  1. One Database, Two Engines: Combines ACID transactional safety (Postgres) with lightning-fast analytical performance (DuckDB) in the same managed server.
  2. Zero Data Movement: Query the Data Lake or object storage directly with SQL without moving data through external pipelines.
  3. Unified Hybrid Analytics: Join live relational operational data with external large files in a single SQL statement.
  4. 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

See more

PostgreSQL Administration