Alibaba Cloud PolarDB for PostgreSQL

PolarDB for PostgreSQL is Alibaba Cloud's cloud-native PostgreSQL-compatible database: compute and storage are separated, nodes in a cluster share distributed storage, and read nodes scale independently of the primary. Architecturally it sits in the same category as Aurora — a PostgreSQL-compatible engine on vendor-built shared storage — inside the Alibaba Cloud ecosystem. For the cross-provider view, see the cloud service map.

Where PolarDB fits

PolarDB is a candidate when your infrastructure already runs on Alibaba Cloud, or when workloads must be deployed in mainland China regions where AWS and Google Cloud do not operate. It is a poor fit if you need tight integration with AWS or GCP services, or if you require community PostgreSQL minor versions the week they ship — managed engines on any vendor trail the community release calendar.

As of 2026-08, PolarDB for PostgreSQL supports community majors 11, 14, 15, 16, 17, and 18 — PostgreSQL 18 compatibility was released in December 2025 — per the official major version lifecycle. Note that Alibaba Cloud also operates a separate Oracle-syntax-compatible PolarDB edition; confirm you are evaluating the PostgreSQL edition.

Architecture and compatibility

• Shared distributed storage. Compute nodes mount a shared storage volume with replicas across availability zones, so adding a read node does not copy the dataset.
• Elastic operations. Compute specifications and node counts change independently of storage; failover promotes an existing read node.
• Extension allowlist. Available extensions and their versions are per engine version and per kernel minor release; diff your requirements against the official supported plugin list rather than assuming community parity.
• Open-source lineage. The PolarDB for PostgreSQL kernel is also published as open source (openpolardb.com), which matters for evaluation and long-term exit thinking — though the managed service and the open-source build are not the same artifact.

China residency and compliance perspective

Residency is the strongest reason to shortlist PolarDB, and it deserves precision:

• Mainland China regions are operated under Chinese regulation by Alibaba Cloud's China entity, with a separate account system from Alibaba Cloud International. Accounts, billing, and support do not transfer between the two.
• If users and data must remain in mainland China — for latency, ICP-related deployment, or data-residency obligations — a China-region PolarDB cluster satisfies constraints that no AWS or GCP region can.
• Conversely, storing personal information of China-based users in an International-region cluster raises cross-border transfer questions under PIPL. Neither direction is self-certifying: confirm the current requirements with counsel or your compliance team, and document which account, region, and legal entity holds the data.

Differences to accept

• Parameter and privilege controls. As on other managed engines, some parameters are locked or platform-managed, and superuser-equivalent access is not available.
• Minor-version lag. Community minor releases arrive on Alibaba's kernel schedule, not the community's; check the release notes for the kernel version behind a given PostgreSQL major.
• Pricing comparisons are not portable. Instance, storage, and node billing differ structurally from both Alibaba RDS for PostgreSQL and AWS Aurora; model your own workload in the Alibaba Cloud pricing calculator instead of trusting percentage claims.
• Tooling ecosystem. Console, CLI, monitoring, and migration (DTS) are Alibaba-specific; operational runbooks from other clouds do not transfer directly.

Validate before production

1. Diff required extensions — pgvector, pg_trgm, PostGIS, pg_cron, and anything version-sensitive — against the supported plugin list for your target engine version.
2. Check parameter compatibility for any non-default postgresql.conf settings you rely on.
3. Rehearse migration with Alibaba DTS (full plus incremental) or pg_dump, including a rollback plan and a character-set check.
4. Run a failover drill and measure reconnection behavior through your driver and pooler.
5. If you need cross-region or cross-border replicas, validate the Global Database Network feature against your residency obligations first.
6. Export once with native tools and restore into an independent PostgreSQL environment as an exit-path test.

For connection budgeting, backup drills, and monitoring baselines that apply on any provider, see the production stack guide. Development-scale evaluation options are covered in the free PostgreSQL guide.