By Awide Labs open-sourced Awide Polar on October 19 — a PostgreSQL fork built on the same architectural principle that powers Amazon Aurora and Google AlloyDB: disaggregated compute and storage. Instead of every replica carrying its own full data copy, all compute nodes share one storage layer. You get 150,000+ TPS in benchmarks, a built-in analytics engine that eliminates the separate OLAP database, and a Docker quick-start that runs in five minutes. The MIT license puts it on any cloud or bare metal you choose.
The Problem With Traditional Postgres Scaling
Standard PostgreSQL uses a shared-nothing architecture. Every node — primary and each replica — stores its own complete copy of the data. Add a read replica, add a full storage copy. Run six replicas, pay for six storage volumes. Scale storage, scale compute. The two are inseparably coupled.
This works fine for small deployments. At scale, it creates a painful coupling: you cannot add read capacity without adding storage cost, and failover requires replaying WAL from the last checkpoint before a new primary can serve traffic. Aurora broke this model in 2017 for AWS users. Awide Polar brings the same architectural shift to open source.
How Shared Storage Changes the Math
Awide Polar’s compute nodes share a single storage layer via PolarFS, a custom user-space distributed filesystem. Six compute nodes cost the same storage as one. Adding a read replica takes seconds — no data copy, just a new compute process pointed at the existing storage. Failover is near-instant because the new primary does not need to reconstruct state from WAL replay; the storage is already consistent.
The Polar Proxy layer, built on ProxySQL, handles LSN-aware read routing. It tracks the primary’s log sequence number and routes reads only to replicas that have already applied the writes. This kills the classic Postgres read-replica footgun: writing on primary and reading stale data from a replica. The same guarantee Neon and Aurora provide is now available in a self-hosted setup.
HTAP: One Database Instead of Two
The standard Postgres analytics setup is a second database. You run Postgres for OLTP and sync rows to ClickHouse, Redshift, or BigQuery for dashboards. That means two pipelines, two failure surfaces, and data that is always a few minutes (or hours) behind.
Awide Polar includes an elastic parallel query (ePQ) engine that fans analytical queries across all read-only nodes simultaneously. The underlying engine integrates DuckDB’s vectorized execution through an in-memory column index (IMCI) layer. Complex analytical queries run 60–100x faster than the row-store engine on the same data. At DOP 8, it benchmarks 5–6x faster than MPP databases. Dashboards run against live data without a separate warehouse or ETL job.
Engine Improvements Over Upstream PolarDB
Awide Polar is not a straight PolarDB fork. It ships several improvements that address known performance cliffs in shared-storage databases under heavy write load:
- WAL pipelining: Dedicated WAL write and flush workers replace the single WAL writer, eliminating the serialization bottleneck at high concurrency.
- CSN-based MVCC: Commit Sequence Number snapshots, ported from PolarDB 11, replace the older transaction ID-based snapshot array. This cuts snapshot overhead for long-running read queries running alongside writes.
- PolarFS storage: The custom filesystem delivers 7x random-write and 11x random-read IOPS compared to the upstream PolarFS baseline, measured with fio at 512 concurrent clients.
The overall throughput result: 150,000+ TPS in pgbench read/write benchmarks. That is the headline number, and it holds up because the WAL pipeline and CSN changes address the write path specifically.
Who Should Try Awide Polar
There is a clear target audience and it is not everyone.
Good fit: Teams running large PostgreSQL clusters in the cloud who are paying for multiple storage copies across replicas. Teams currently operating Postgres alongside a separate OLAP system. Teams tired of Patroni failover complexity — Awide Polar includes extended Patroni integration and the shared storage model makes failover fundamentally simpler.
Not a fit: Single-node deployments, small applications, or teams without the infrastructure appetite for a custom storage filesystem. The PolarFS requirement means you cannot bolt Awide Polar onto an existing PostgreSQL cluster as a drop-in upgrade.
For evaluation, the Docker quick-start is the lowest-friction path:
docker pull awide-labs/awide-polar-local:15
docker run -it --cap-add=SYS_PTRACE --privileged=true --rm \
awide-labs/awide-polar-local:15 psqlThe three repositories cover everything you need: the main engine at awide-labs/polar, the storage layer at awide-labs/polarfs, and the proxy at awide-labs/polar-proxy. The HTAP parallel query engine is currently at Postgres 15 compatibility; a Postgres 17 port is in progress. Aurora-style shared-storage PostgreSQL has been closed-source or managed-only since 2017. It is worth understanding the architecture even if you do not switch today — and now there is an open codebase to read.
