20+ Analytics & Columnar Extensions for PostgreSQL

Citus, Hydra, pg_duckdb, pg_parquet, and other Postgres extensions for analytics, columnar storage, and lakehouse queries. Ranked by GitHub stars.

Last reviewed: June 5, 2026
14 extensions
AllVector & AIFull-text SearchGeospatialTime-series & TemporalAnalytics & ColumnarForeign Data WrappersMonitoring & Stats
Platform
Self-HostedSupabaseAWS RDSNeonAzureAuroraCloud SQLAlloyDBDigitalOceanCrunchy BridgeAivenHeroku
1
citus
12.5k+70 30d

Distributed PostgreSQL as an extension

Analytics & Columnar·AGPL-3.0·C
2
pg_duckdb
3.1k+58 30d

DuckDB Embedded in Postgres

Analytics & Columnar·MIT·C++
3
columnar
3.0k+1 30d

Hydra Columnar extension

Analytics & Columnar·Apache-2.0·C
4
pg_partman
2.7k+24 30d

Extension to manage partitioned tables by time or ID

Analytics & Columnar·PostgreSQL·C
5
pg_mooncake
2.0k+9 30d

Columnstore Table in Postgres

Analytics & Columnar·MIT·C++
6
cstore_fdw
1.8k0 30d

Provides columnar storage for analytics workloads via a foreign data wrapper, with ORC-inspired compression and skip indexes.

Analytics & Columnar·Apache-2.0·C
7
pg-strom
1.4k+2 30d

PG-Strom - big-data processing acceleration using GPU and NVME

Analytics & Columnar·PostgreSQL·C
8
pg_parquet
674+4 30d

copy data between Postgres and Parquet

Analytics & Columnar·PostgreSQL·Rust
9
duckdb_fdw
405+1 30d

DuckDB Foreign Data Wrapper

Analytics & Columnar·MIT·C
10
postgres_vectorization_test
3350 30d

Implements a vectorized executor for PostgreSQL over the cstore_fdw columnar store to speed up analytic queries.

Analytics & Columnar·Apache-2.0·C
11
imcs
2010 30d

Provides an in-memory columnar store for accelerating analytical queries.

Analytics & Columnar·Apache-2.0·C
12
plproxy
1920 30d

Database partitioning implemented as procedural language

Analytics & Columnar·BSD 0-Clause·C
13
vops
1630 30d

Speeds up OLAP queries in PostgreSQL using vectorized columnar tiles and chunk-based execution.

Analytics & Columnar·C
14
vectorize_engine
290 30d

Accelerates PostgreSQL query execution using vectorized executor nodes via the CustomScan framework.

Analytics & Columnar·C

What is a PostgreSQL Analytics Extension?

Analytical extensions transform Postgres from a row-store OLTP database into a hybrid OLAP engine — adding columnar storage (Hydra/columnar, Citus columnar), embedded execution engines (pg_duckdb runs DuckDB inside Postgres), distributed query planning (Citus shards tables across nodes), and lakehouse integration (pg_parquet, pg_mooncake, pg_lakehouse for Iceberg/Delta). They let teams run analytical queries — aggregations, scans over billions of rows, joins across data lakes — without maintaining a separate data warehouse like Snowflake, BigQuery, or Redshift. The result: one database, one auth model, one operational story for both transactional and analytical workloads.

When to Add an Analytics Extension

Use these when analytical query volume strains your transactional Postgres but you don't want to move data to a separate warehouse. Citus is the choice when you need horizontal scaling with a familiar SQL interface — sharded tables across nodes, distributed joins, parallel aggregations. pg_duckdb is best for ad-hoc analytics directly on Postgres tables or remote Parquet files (sub-second on millions of rows). Hydra and columnar compress historical data 5-10x and make aggregations dramatically faster. Stay with plain Postgres if your analytical queries return in seconds already — extensions add operational overhead, only worth it when the gains justify it.

Frequently Asked Questions

What is Citus?
Citus is a PostgreSQL extension that transparently shards tables across multiple Postgres nodes — turning Postgres into a distributed SQL database. You create 'distributed tables' partitioned by a key (tenant_id, customer_id, etc.), and Citus routes queries to the right shards and parallelizes joins and aggregations across the cluster. AGPL-licensed, maintained by Microsoft (acquired Citus Data in 2019), and available as Azure Cosmos DB for PostgreSQL. Single-node Citus is also widely used for columnar storage on a single machine.
What's the difference between Citus and Hydra?
Citus focuses on distributed query execution across nodes (sharding, parallel joins, horizontal scaling). Hydra focuses on columnar storage on a single node — its columnar engine compresses tables and accelerates analytical scans, but doesn't shard. They're complementary: many Hydra deployments use Citus columnar (Citus's columnar engine, which Hydra also uses under the hood since Hydra forked from it). For a single big machine doing analytics, Hydra is simpler. For multi-node scale-out, use Citus.
Can Postgres replace a data warehouse?
For teams under ~1 TB of analytical data, yes — Postgres with Citus columnar, Hydra, or pg_duckdb can match Snowflake and BigQuery on query speed at a fraction of the cost. For teams managing 10+ TB with hundreds of concurrent analyst queries, a purpose-built warehouse still wins on workload management, separation of compute from storage, and operational features. The sweet spot for Postgres-as-warehouse is the analytics needs of a typical product company that doesn't yet have a dedicated data platform team.
Does pg_duckdb work on managed Postgres?
Limited support currently. pg_duckdb is relatively new (released 2024) and requires a shared library, so most managed providers haven't enabled it yet — check AWS RDS, Supabase, and Neon's current extension allow-lists. Self-hosted Postgres and Postgres-compatible analytics platforms like MotherDuck and Tembo are the main supported paths today. For managed providers without pg_duckdb, alternatives are foreign data wrappers (parquet_fdw, pg_lakehouse) or running DuckDB separately and federating via postgres_fdw.
When should I use a columnar extension vs vanilla Postgres?
Add a columnar extension when your queries scan large fractions of a table for aggregations — sums, averages, group-bys over millions to billions of rows. Columnar storage compresses better (5-10x typical) and reads only the columns the query needs, both dramatically faster than row-store for these patterns. Stay row-store for transactional workloads where you read whole rows by primary key or do narrow filtered queries — columnar formats are slower for those patterns and don't support UPDATE/DELETE as efficiently.

Manage PostgreSQL Visually

1bench is a modern GUI client for PostgreSQL — install extensions, write queries, and inspect schemas without leaving the IDE.

Try 1bench for PostgreSQL