# PolarDB for PostgreSQL: Alibaba's shared-storage rework of Postgres 17 > A C fork of PostgreSQL that separates compute from storage, adds a LogIndex replay layer and an MPP engine for mixed OLTP and OLAP work, and carries an Apache-2.0 licence. The interesting parts are the architecture and the upgrade cost. **polardb/PolarDB-for-PostgreSQL** — A cloud-native database based on PostgreSQL developed by Alibaba Cloud. - Repository: https://github.com/polardb/PolarDB-for-PostgreSQL - Website: https://polardb.github.io/polardb-pg-docs/zh/ - Stars: 3,210 · Forks: 525 - Language: C - License: Apache-2.0 - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/polardb-polardb-for-postgresql ## One copy of data behind many compute nodes PolarDB starts from a problem every Postgres replication setup runs into: adding read capacity means copying the whole data set to every new node. The README states the change numerically, turning N copies of data in the compute cluster plus N copies in the storage cluster into N copies in the compute cluster and one copy in the storage cluster. Shared storage holds the single authoritative copy while each compute node maintains its own in-memory state, and the write-ahead log living in that shared storage is what the nodes agree on. Keeping one copy is the easy half. Visibility is the hard half. When the primary flushes a dirty page, the read-only nodes must not read a page from the future, and they must equally not read an outdated page that has not been replayed correctly in memory. PolarDB handles this with LogIndex, an index structure that maintains the page replay history and synchronizes the primary with the read-only nodes. The same layer offers two replay modes, lazy replay and parallel replay, and the README's millisecond-level latency claim rests on those modes. ## What the POLARDB_17_STABLE branch and its tags tell you The stable line is the `POLARDB_17_STABLE` branch, which the README describes as the stable branch based on PostgreSQL 17 that supports the compute-storage separation architecture. The repository is C, licensed Apache-2.0, and its top level still reads like Postgres itself: `configure`, `configure.ac`, `aclocal.m4`, `GNUmakefile.in`, `Makefile`, `src/`, `contrib/`, `doc/`, `package/` and an `external/` directory for third-party code. Two additions stand out. `meson.build` and `meson_options.txt` bring the Meson build system in alongside the autotools path, and `build.sh` sits next to them as a wrapper. Continuous integration has moved too: `.cirrus.yml` and `.cirrus.tasks.yml` stand where Postgres historically used Travis. The tags are versioned the Postgres way, four numbers instead of semver. `v17.11.1.0` and `v15.19.5.0` were both published on 2026-08-18, and `v17.10.1.0` came on 2026-05-30. Two parallel branches tell you something practical: the fork tracks upstream minor releases on both PostgreSQL 17 and the older 15 line, so moving forward means merging upstream work rather than bumping a number. `.abi-compliance-history` at the top of the tree is the record the project keeps of exactly that. ## Starting a local instance from a container image The quick start is a Docker image and a psql prompt. Two commands are the whole install: ```bash docker pull polardb/polardb_pg_local_instance:17 docker run -it --cap-add=SYS_PTRACE --privileged=true --rm polardb/polardb_pg_local_instance:17 psql ``` The tag `17` pins the PostgreSQL major line. `--cap-add=SYS_PTRACE` and `--privileged=true` are there because a PostgreSQL build wants to inspect its own process memory for debugging and to touch shared memory segments, neither of which a default container grants. The check afterward is a version query, and the output tells you whether the fork is actually in the image: ```bash postgres=# SELECT version(); version ---------------------------------------------------------------------- PostgreSQL 17.x (PolarDB 17.x.x.x build xxxxxxxx) on {your_platform} (1 row) ``` Note the limits of that image. The README calls it an instance image based on local storage, so it exercises the engine and the PolarDB extensions but not the shared-storage cluster, which is the actual subject of the project. For a multi-node setup the README points you at its Advanced Deployment page, and nothing in the repository itself covers the deployment path. ## The MPP engine behind the HTAP claim Decoupling storage has an obvious side effect. Once every node reads through shared storage, one read-only node handling a large analytical query is leaving the storage bandwidth of the whole cluster idle, along with most of the other nodes' CPU and memory. PolarDB's answer is a shared-storage massively parallel processing engine that pushes work across nodes at SQL level rather than leaving one node to grind through it. The README describes two execution modes inside that engine. Standalone execution handles OLTP queries with high concurrency. Distributed execution handles the large OLAP queries. Both run against the same OLTP data types, which is the whole point of the hybrid transactional and analytical processing label: the same rows, the same tables, the same transactions, without a second copy of the data in a column store. The honest reading is that this is a research and product architecture described in marketing prose. The README states what the modes are for but publishes no workload, no data volume and no latency comparison against stock PostgreSQL, so a reader has to take the HTAP claim on structure alone. Anyone planning around it should treat the architecture page as the specification and find their own numbers before committing. ## Multi-model types and where the README stops The README also lists spatio-temporal, geographic information system, image, vector and graph data among the types PolarDB handles. That is a list of intentions rather than a documented feature set: no extension names, no version numbers and no examples appear in the repository for any of them. That is the boundary worth drawing early. The repository is a good statement of what the project is trying to be: a cloud-native database service, developed by Alibaba Cloud, described as 100% compatible with PostgreSQL, with shared storage, millisecond latency and HTAP in the opening paragraphs. It also carries the branch list, the build files, the CI configuration and the licence. Everything a deployment decision needs sits one hop away on polardb.github.io: the architecture overview, the deployment guide, and per-version documentation behind an English and Simplified Chinese toggle that the README exposes as `README_zh.md`. The repository itself settles what PolarDB is. It does not settle how to run it in a cluster, how to fail over, or what it costs. ## The cost of forking Postgres, and who should pay it Apache-2.0 removes the licensing question that stops many enterprises from adopting a vendor fork: the code can be read, modified and shipped, and the documentation site is public rather than gated behind a contract. Sixty-six open issues against a codebase of Postgres's size is a modest queue, and the last push was on 2026-09-23 on a repository with 3,204 stars and 523 forks. The real expense is the fork itself. PolarDB sits on PostgreSQL 17 and tracks two major lines at once, which means every upstream minor release arrives as a merge that has to be resolved against LogIndex, the replay machinery and the MPP engine. That work does not disappear because the licence is permissive. A team already running stock PostgreSQL with a hot standby gets read scaling from machinery it already understands, and it keeps the option of a point upgrade to the next upstream release. The people who should pay the merge cost are those who hit the wall shared storage was built for: a data set that no longer fits one host, combined with analytical queries that need every core in the cluster rather than one node. Everyone else should read the architecture pages, then weigh an ordinary replica against a compute-storage split before installing anything. ## Conclusion PolarDB makes sense when one workload is eating read capacity while the storage underneath is already larger than a single host, because the shared-storage design is aimed exactly at that. It makes little sense for a database that fits on one machine, where a standby replica is cheaper to reason about, or for anyone who wants to track upstream PostgreSQL without merging. The repository settles the architecture question in detail and settles almost nothing about day-two operation: no upgrade procedure, no failover story and no benchmark figures appear anywhere in it. Start with the local instance image to confirm the fork behaves like Postgres, then read the architecture pages on polardb.github.io before budgeting the merge work that meson.build and .abi-compliance-history imply. ## FAQ ### What is PolarDB for PostgreSQL Enterprise Edition? The repository does not describe editions at all. What it publishes is the PolarDB for PostgreSQL source under Apache-2.0, with a stable branch for PostgreSQL 17 and a separate line for 15, plus documentation on polardb.github.io that covers the architecture and deployment in more depth than the README does. ### Is there a free database that uses PostgreSQL? PolarDB is a fork of PostgreSQL rather than a system built on top of it, and the source is Apache-2.0, so there is no licence fee for the code itself. The README's quick start runs the engine from a public container image, and the costs that do exist are operational: the shared storage cluster and the fork maintenance that go with it. ### How do I run PolarDB for PostgreSQL locally before deploying a cluster? Pull the instance image for the PostgreSQL major line you want and start it with psql attached, which gives you a local-storage single node rather than the shared-storage architecture. That is enough to confirm the fork reports itself as PolarDB under `SELECT version();` before you read the deployment guide for the clustered setup. ## Sources - [License: Apache-2.0](https://github.com/polardb/PolarDB-for-PostgreSQL/blob/POLARDB_17_STABLE/LICENSE) - [polardb/PolarDB-for-PostgreSQL on GitHub](https://github.com/polardb/PolarDB-for-PostgreSQL) - [Project website](https://polardb.github.io/polardb-pg-docs/zh/) - [README](https://github.com/polardb/PolarDB-for-PostgreSQL/blob/POLARDB_17_STABLE/README.md) - [Releases](https://github.com/polardb/PolarDB-for-PostgreSQL/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/polardb-polardb-for-postgresql