Awide Polar separates compute and storage in PostgreSQL, aims at HTAP without ETL

A fork of a fork, open source

On October 19, 2026, Awide Labs published the source code for Awide Polar, a project that builds on PolarDB for PostgreSQL (the fork Alibaba has maintained for years) and applies its own changes on top of the PostgreSQL 17 base. Along with the engine, the company also open-sourced PolarFS, the shared storage layer, and Polar Proxy, a ProxySQL-based proxy for consistency-aware routing across replicas.

For system architects, the central point isn't the announcement itself, but the architecture behind it: separating compute and storage within PostgreSQL, without rewriting the application. This addresses a concrete problem for anyone who has tried to scale reads on vanilla Postgres, where each physical replica carries a full copy of the data and storage cost grows along with compute cost, even when all that's needed is more read capacity.

How storage separation works

In Awide Polar's design, a primary handles writes, and read replicas access the same data files through PolarFS, the shared file system. Adding a replica doesn't mean keeping another full copy of the database: the replica points to the same storage and only needs processing capacity.

This changes the capacity math for anyone running the database in production. Today, with PostgreSQL's traditional physical replication, doubling read capacity costs twice the disk. In Awide Polar's architecture, compute and storage scale on separate axes, without application sharding.

The model remains single-writer: a single primary accepts writes, and replicas serve reads and analytical work. The performance work announced by Awide Labs targets precisely this single writer's commit path, not distributed writes across multiple nodes.

What changed in the engine and storage

Awide Labs describes three engineering fronts in the original publication, each addressing a different point of contention:

• Database engine: WAL pipelining and CSN-based MVCC, ported from PolarDB 11 to the PostgreSQL 17 base, with dedicated WAL write and flush workers and finer lock partitioning in WAL insertion, buffer mapping, flush lists, and LogIndex.
• PolarFS: replacing polling-based communication with lock-free queues and futex wake-ups, registered shared buffers for zero-copy I/O between PostgreSQL and the storage daemon, plus sharded caches and finer-grained locking.
• Polar Proxy: LSN-aware routing on top of ProxySQL, with support for prepared statements and the extended query protocol.

In pgbench tests with mixed read-write load, Awide Labs reports more than 150,000 transactions per second. In fio tests with 512 clients, PolarFS reportedly delivered about 7 times the random write IOPS and 11 times the random read IOPS of the original PolarFS version.

It's worth noting the caveat Awide Labs itself makes: these are two distinct benchmarks, with different objectives, and neither comes with hardware specifications, dataset size, or connection configuration. For a DBA evaluating the technology, this is a starting point for reproducing the test in their own environment before deciding anything, not a number to plug into capacity planning.

Read consistency on replicas: the proxy's role

Shared storage solves data duplication, but opens another classic replication problem: a replica can respond with data that's stale relative to what the client just wrote to the primary. This is where Polar Proxy comes in, with two modes of operation.

In session mode, the proxy guarantees that a client reads its own committed writes even when the read lands on a replica. In global mode, any read on a replica waits for the most recent LSN observed by the proxy across all sessions, trading a bit of latency for a stronger consistency guarantee between different clients.

Awide Labs itself is explicit about the limit of this guarantee:

This proxy-level global mode is distinct from globally coordinated transaction snapshots, which remain planned work.

Vadim Iatsenko, Awide Labs

In other words: the proxy solves read consistency on an individual replica, but it doesn't deliver coordinated snapshot isolation across multiple transactions throughout the cluster. For those designing systems that depend on strong isolation between concurrent transactions on different replicas, this distinction decides whether the architecture works today or only once this planned work leaves the drawing board.

HTAP without an ETL pipeline

The project's second front is HTAP: Polar's elastic parallel query engine distributes analytical work across replica workers that access the same row-oriented data used by transactions. In practice, this avoids maintaining a separate ETL pipeline just to feed an analytical database with the same data that's already in the transactional one.

The feature was already ported to Awide Polar 15; porting to version 17, which is the base for the rest of the project, remains in progress according to Awide Labs. It's worth noting that, even with analytical compute isolated on replicas, storage remains shared: a heavy analytical query still competes for I/O with transactional traffic on the same PolarFS, it just doesn't compete for CPU on the same node.

High availability and what the fix list reveals

Awide Labs extended Patroni to understand PolarDB's shared storage topology and ported DataMax, a WAL-only relay, to Awide Polar 17. A nearby DataMax receives WAL synchronously and forwards it asynchronously to a remote standby, taking remote replication latency out of the primary's commit path. Standby promotion is guarded: it fetches the remaining WAL before taking over, but recovery without data loss depends on that acknowledged WAL remaining available, including on DataMax itself.

The publication also lists fixes for stale reads on replicas, visibility and snapshot issues tied to CSN, promotion failures and WAL fsync error handling, plus a cross-host read-write lease in PolarFS to protect against concurrent writers. For a DBA, this list isn't a reason for alarm: it's a sign that Awide Labs tested real failure scenarios before open-sourcing the code. But it's also a reminder that this is a young fork, open for only a few hours, without the production track record that vanilla PostgreSQL or the original PolarDB have already accumulated.

When it makes sense to consider

Awide Polar's architecture serves a specific scenario well: applications with reads far exceeding writes, which today pay the cost of duplicating data with every replica, or teams that want to run analytics on operational data without maintaining an ETL pipeline to a separate data warehouse.

It doesn't solve, at least in this version, distributed writes across multiple nodes, since the model remains single-writer. Teams that need horizontal write scaling, guaranteed compatibility with the entire PostgreSQL extension ecosystem, or an extensive production track record before trusting critical data to an engine should treat Awide Polar, for now, as a project to evaluate in a controlled environment, not as an immediate replacement for an established PostgreSQL installation. The code is in the Awide Labs organization's repositories on GitHub, and the company promises more detailed technical posts about the engine, storage, and proxy in the coming weeks.