PolarDB

1. Shared storage + physical replication single-writer/multi-reader: adding read nodes moves no data What it's really good at: compute-storage separation — all nodes (including up to 15 read-only nodes) mount the same PolarStore distributed storage; inter-node sync uses redo physical replication rather than binlog/WAL logical replication. Compared to RDS (adding a replica = full data copy + logical replay, hours at TB scale), PolarDB adds read-only nodes without copying data — it only pulls metadata and catches up on incremental redo. That is the mechanistic root cause of "minute-level read scaling"; millisecond-level replication lag shrinks the "read stale data under read/write splitting" window by an order of magnitude versus RDS primary-replica setups. Edge truth: ① A read-only node is a "stateless compute node", not a "data replica" — the real data redundancy lives in the storage layer's 3 replicas; node failover is fast, but a storage-layer problem is a different failure domain — don't mistake "second-level node recovery" for "data can't be lost". ② Under a write burst, redo generation speed > read-only node replay speed, lag blows up — "millisecond-level" is a steady-state value, not a commitment. ③ Read scaling ≠ write scaling — the write ceiling is always the single primary. This is the original sin shared by the whole Aurora lineage and the easiest thing to misjudge in selection. Evidence & versions: official FAQ (read-only node onboarding, millisecond-level lag statement); community load-test consensus; applies to PolarDB for MySQL 8.0 / PG 14+ all versions.
2. PolarProxy: read/write splitting, connection pooling, and consistency levels built into the infrastructure layer What it's really good at: a mandatory transparent proxy for the cluster that automatically does read/write splitting, statement-level/transaction-level connection multiplexing, and routing by consistency level (global/session/eventual consistency; the PG edition builds strongly consistent read views with CSN). Compared to self-hosted PG (where you have to assemble pgbouncer + a read/write-splitting middleware + consistency policies yourself), PolarDB turns all three into out-of-the-box infrastructure. Real load-test evidence: under equal pressure, PolarDB-PG memory was significantly lower than native PG — the direct effect of the proxy absorbing connection storms. This is the source of users' "zero-change access to a PG connection pool + read/write splitting" experience. Edge truth: ① The proxy is on the mandatory path — one extra network hop, and a proxy version upgrade = connection blips (see complaints table); ② the proxy's SQL parsing has boundaries — complex protocol features / large objects / certain admin commands may need to bypass the proxy and connect directly, so applications should keep a direct-to-primary escape hatch; ③ the DBA's observability is one layer removed behind the proxy — slow-SQL attribution and connection killing both need a rebuilt methodology — the cost of "transparent" is "black box". Evidence & versions: CSDN real migration case (2025); official consistency-level docs; applies to all versions, connection-pool benefits most pronounced on the PG edition.
3. Storage-layer ROW snapshot backup: second-level backups + mandatory Level-1 backups What it's really good at: backups happen at the PolarStore storage layer as Redirect-on-Write snapshots, copying no data; Level-1 backups (3–730 day retention) are enabled by default and cannot be disabled; Level-2 backups are compressed and transferred to offline storage (OSS). Compared to self-hosted MySQL logical backups (table locks / slow / even slower restore) and RDS backup windows, PolarDB backups are "unperceived storage-layer operations" — second-level regardless of database size. This is a capability the compute-storage separation architecture gets for free and traditional architectures cannot match. Edge truth: ① "Cannot be disabled" = forced backup storage billing — there is no "don't back up" option in the backup policy; ② when a Level-2 backup transfer fails, expiring backups are deleted directly (verified in official docs) — large-database users may silently lose their backup chain; ③ recovery means "spin up a new cluster" (does not overwrite the original cluster, does not inherit source cluster parameter settings); the vendor's 10-minute-level recovery statement is strongly correlated with data volume — don't treat it as an RTO commitment. Evidence & versions: official Backup and Recovery docs (help.aliyun.com); applies to PolarDB for MySQL / PG all versions.
4. Serverless elastic billing (PCU model): compute per second, storage by usage What it's really good at: compute resources billed per second in PCU units and settled hourly, scaling down to 0–1 PCU when idle (PG Agentic Database supports Scale to Zero); storage billed independently by actual usage. Compared to RDS's "buy specs on subscription" pricing model, this is PolarDB's genuine business-model differentiator — spiky businesses (promotions, SaaS idle overnight) don't pay for peak capacity. Note this is a "billing model innovation", not a "technology innovation", but it's a real difference on a CTO's budget sheet. Edge truth: ① Elasticity lags: second-level detection + spin-up can't handle sub-minute spikes — the first requests may get throttled; ② each form has PCU lower/upper bounds (e.g., 0–8 PCU) — workloads exceeding them can't use Serverless; ③ steady-load businesses may find actual bills higher than subscription pricing, and unpredictable bills are a genuine finance-team complaint; ④ the "35% cost reduction" is a vendor claim — it holds only if "your load really is spiky" — Serverless without spikiness is reverse optimization; ⑤ the exact terms for auto-pause triggers (how long without traffic, which states block pausing such as read-only nodes / long connections / scheduled jobs) were not found in public docs — to-be-verified; applications with long-lived connections may never trigger auto-pause. Evidence & versions: official PolarDB-PG form-comparison and billing docs (2026); community selection consensus; applies to MySQL Serverless, PG nimble Serverless.

Deep dive 1 (compute-storage separation architecture): PolarFS / PolarStore — "data replication" replaced by "the storage layer is a logical single point"

• Mechanism: compute nodes are fully separated from storage; the storage layer is Alibaba's self-developed distributed filesystem PolarFS running on 3-replica PolarStore; all compute nodes in a cluster (1 primary + up to 15 read-only) share the same physical data; read-only nodes replicate no data — they only read redo from shared storage and sync in-memory metadata, with MVCC guaranteeing cross-node read consistency (official docs / developer community).
• Pushed to the edge: ① The real primary-failure process: replica takeover moves no data — failover is essentially the transfer of "redo ownership + primary role", and the mechanistic basis for RPO=0 is that a transaction only commits after redo lands on 3 replicas (official statement). But the real costs come in three layers: at failover the old primary actively disconnects all existing connections (official docs state this is expected behavior) — applications see Communications link failure, not a transparent drift; the new primary's Buffer Pool is empty, and during the cold-start warm-up, query latency can reach 2–5× normal for several minutes (community ops articles citing Alibaba internal practice, community consensus); failover itself is a vendor claim of "within 30 seconds", but business-perceived interruption is often amplified by the application layer to 1–3 minutes (dead connections in pools + herd reconnection, community-tested cases). ② Compute-layer behavior under storage-layer jitter/split-brain: engineering protections include Multi-path links + RTT-based routing for NIC flapping, and compute-side PolarSwitch I/O-depth limiting + storage-side backpressure for many-to-many Incast congestion (official TPC-C technical deep-dive article). Dual-primary writes cannot happen — writes must be arbitrated by the storage layer (redo 3-replica majority confirmation); a network-isolated old primary can't write to storage and naturally loses primary eligibility; but during a compute-layer network partition, read-only nodes can still serve reads — reads see pre-partition stale data — that's the cost of choosing "eventual consistency". There are virtually no real-world postmortems of PolarDB storage-layer split-brain in public channels; the quantitative behavior of storage jitter propagating to the compute layer is marked 待验证. ③ The cost of "adding read nodes moves no data": adding a node takes ~5 minutes with data immediately visible, but the new node's memory is cold — read performance is discounted before warm-up; read-only node redo replay itself consumes CPU, and the official FAQ states verbatim: an overloaded read-only node "steals resources that belong to the application's redo logs", directly increasing replication lag — a read node is not free; it shares the same storage I/O and redo bandwidth budget as the primary; the primary's write-throughput ceiling moves from "local disks" to "shared storage IOPS/bandwidth" — the storage layer becomes the new bottleneck in hotspot small-write-intensive scenarios (mechanism derivation, to-be-verified).
• Selection implication: compute-storage separation trades the "data replication" problem for a "storage layer is a (logically) strong-dependency single point" problem — the architecture-review question is not "how much primary-replica lag", but "how large is the storage layer's jitter blast radius, and can the control plane observe PolarFS latency". Write-intensive businesses must stress storage IOPS in the POC, not just CPU; read-only node count planning must reserve CPU headroom for redo replay — don't linearly extrapolate from "pure-read QPS". The MySQL and PG engines behave identically in this architecture; PolarDB-O inherits the same mechanism from the PG engine.
• Sources: mechanism and node-addition/replication-lag-increase conditions — official docs FAQ 官方文档; disconnection-on-failover as expected behavior, 2–5× cold-start latency — Alibaba Cloud developer community ops field-testing articles (community-tested, 2026); PolarStore anti-jitter design — official TPC-C technical deep-dive (official docs, vendor-claim components stripped, mechanism descriptions only); split-brain behavior — mechanism derivation + absence of public postmortems 待验证

Deep dive 2 (Oracle compatibility): PolarDB-O's real coverage — "syntax runs" ≠ "semantics equivalent"

• Mechanism: PolarDB-O is an Oracle-syntax compatibility layer on the PG kernel (SPL procedural language, Oracle dictionary views, data-type mappings); the public-cloud version is Oracle 2.0 (based on PG 11, official international-site docs), kernel closed-source; a separate PG 14-based commercial kernel is only available through special enterprise-edition customization (Pigsty community records, 2026), not obtainable in the public-cloud standard edition.
• Pushed to the edge (the "compatible but inconsistent" items documented in official docs): ① PL/SQL (SPL): basic syntax, cursors, packages/stored procedures/functions, triggers, sequences, synonyms are officially claimed as supported. But the official English Developer Guide for Oracle Compatibility explicitly lists behavioral differences: autonomous transactions (PRAGMA AUTONOMOUS_TRANSACTION) each consume one connection slot, at most 16 nested levels per session, parallel queries not supported; "not fully compatible with Oracle": if an SPL block ends with an uncommitted transaction, PolarDB-O does not raise an error (Oracle does) — silently swallowing a logic bug that should have surfaced; package functions support STRICT/LEAKPROOF/COST and other PG extension keywords that Oracle doesn't recognize — a reverse pitfall when migrating back from PolarDB-O to Oracle or running dual-write. ② DATE/data types: the DATE type defaults to PG behavior (no time component) — the parameter polar_comp_redwood_date must be set to true to match Oracle — the default is itself a pitfall (developer community tutorial). ③ DBLINK: no native DBLINK support evidence found in official docs or compatibility guides 待验证; community practice uses oracle_fdw/dblink FDWs for external connections, and cross-database distributed transaction semantics are not equivalent to Oracle DBLINK. ④ Partitioned-table global indexes: the official international-site docs list hard limits — no global indexes on non-partitioned tables, no expression index keys, partition-key columns can't be index keys.
• Selection implication: PolarDB-O compatibility is "syntax runs" level, not "semantics equivalent" level. Selection testing must include: connection-slot-exhaustion stress tests for autonomous transactions, exception-handling paths (especially code depending on Oracle error semantics), DATE-type parameter checks, and DBLINK alternative validation. Treating it as "Oracle without code changes" will blow up; treating it as "PG that speaks Oracle dialect" sets expectations correctly. Factual difference reference: EDB Postgres Advanced Server is a privately deployable, cross-cloud software product tracking newer PG major versions; PolarDB-O is an Alibaba Cloud managed service, kernel closed-source, public cloud stuck at Oracle 2.0 on PG 11; OceanBase's Oracle mode is a natively distributed multi-tenant architecture (Paxos multi-replica, tenant-level dual mode); PolarDB-O is a single-machine PG kernel + compute-storage separation (single-writer/multi-reader, non-sharded) — the route choice of "centralized compatibility vs distributed compatibility".
• Sources: compatibility feature list — official docs and developer community 官方文档; autonomous-transaction limits and "not fully compatible" statement — official English SPL developer guide PDF 官方文档; DATE parameter — developer community tutorial 社区实测; PG 14 commercial kernel only via enterprise customization — Pigsty docs (community-tested, 2026-08); EDB/OceanBase differences — public product-form facts (official docs + community consensus); native DBLINK support status 待验证

Deep dive 3 (single-writer/multi-reader and proxy): PolarProxy / cluster endpoint — returns depend on "how much transaction-free pure-read traffic you can split off"

• Mechanism: PolarProxy is the cluster's built-in proxy layer — it parses SQL, sends writes to the primary and distributes reads to read-only nodes; three endpoint types: primary endpoint (primary only), cluster endpoint (automatic read/write splitting), read-only endpoint (reads only); three consistency levels: global consistency (strong), session consistency, eventual consistency (official FAQ).
• Pushed to the edge: ① Real read-lag magnitude: official statement is "millisecond-level". The three officially acknowledged lag-increase conditions (FAQ verbatim): the primary generates so much redo that read-only nodes "can't keep up applying it"; read-only nodes overloaded, stealing replay resources; I/O bottlenecks slowing redo reads/writes. Under promotion-level write bursts the millisecond-level statement breaks; read workloads on eventual consistency will read second-level stale data — this is an architecture-inherent trade-off, not a failure. ② Transaction/temp-table/session-variable pitfalls: once a connection opens a transaction, creates a temp table, or sets session variables, PolarProxy pins that connection to the primary (transaction stickiness) — subsequent reads go to the primary too, making read/write splitting nominal. Frameworks (like Spring's @Transactional) that put transactions on every method by default can end up with zero traffic on read-only nodes and the primary hammered by reads — the most frequent PolarDB read/write-splitting failure mode in the community 社区共识. Temp tables are only visible in the primary-node session; "write temp table, read temp table" across nodes errors out directly on read-only nodes. ③ Connection behavior: connection limits follow each node spec's max_connections 官方文档; PolarProxy itself multiplexes connections. On primary/secondary failover the old primary actively disconnects all connections; for long-lived-connection apps using HikariCP's default maxLifetime=30 minutes, dead connections can linger in the pool for 10 minutes, and combined with "herd reconnection" can instantly crush the newly promoted primary (community-tested case: an e-commerce promotion saw connection-pool errors persist for 3 minutes after failover). A cold fact from the official FAQ: after adding a read-only node, already-established read/write-splitting connections will not automatically route requests to the new node — connections must be dropped and rebuilt (e.g., restart the app) — elastic scale-out is not immediately effective for long-connection applications. ④ Engine differences: the MySQL engine supports thread-pool parameters (loose_thread_pool_*; 8.0.1.1.19+ supports proxy-aware bypass config); the PG engine's PolarProxy is implemented as a MaxScale-based combo (community PolarFlex testing: proxy port 12369); PolarDB-O inherits the PG engine's behavior.
• Selection implication: audit the application's transaction boundaries and session-variable usage before deciding how many read-only nodes to add — otherwise added nodes are decorations. Connection-pool parameters (maxLifetime < database wait_timeout, explicit socketTimeout 5–10 seconds, failover drills) are required answers in PolarDB selection, not optional. Custom cluster endpoints split by business (read/write isolation, weight ratios within 3×) are the production standard (community ops experience).
• Sources: three endpoint types and three consistency levels, replication-lag conditions and causes, new nodes requiring connection rebuild — official docs FAQ 官方文档; failover disconnections/cold starts/connection-pool herd effects/address mixing — developer community field-testing articles (community-tested, 2026); transaction stickiness causing zero traffic on read-only nodes — community consensus (consistent with official read/write-splitting docs at the mechanism level); PG engine MaxScale proxy — Pigsty/PolarFlex community testing 社区实测

Deep dive 4 (billing & elasticity): Serverless — "pay for fluctuation", not "pay for cheap"

• Mechanism: PolarDB MySQL Serverless auto-scales on RCU compute units with actual consumption and supports auto start/stop — after pausing, only storage is billed; the PG edition uses "nimble Serverless" billed on PCU (starting at 1 PCU, 0.5 PCU granularity); the 2026 PG Agentic Database supports scaling to 0 (0–8 PCU, no compute charge when idle) (official help center + community billing breakdowns).
• Pushed to the edge: ① Real cold-start/scale-to-zero behavior: the PG Agentic edition officially supports Scale to Zero / Scale from Zero with fast recovery on requests 官方文档. The MySQL Serverless edition supports auto start/stop with only storage billed when paused (community billing tutorials citing official rules). But the exact auto-pause trigger conditions (how long without traffic, which states block pausing such as read-only nodes / long connections / scheduled jobs) were not found in public docs — 待验证; applications with long-lived connections may never trigger auto-pause — the #1 hidden killer of Serverless savings (mechanism derivation). ② The "pay-as-you-go is actually more expensive" load profile: pay-as-you-go unit prices are naturally higher than amortized subscription prices. For instances running 7×24 at stable high water marks, Serverless bills accumulated on actual RCU/PCU will exceed subscription pricing for the same spec; Serverless wins for tidal loads with 5–10× peak-to-valley ratios, dev/test environments, and businesses with near-zero requests at night (community billing breakdown articles' selection advice, a mechanistic conclusion). Note that storage and compute are billed separately: storage is billed per GB per hour by actual usage — compute pausing doesn't stop storage charges — "scaling to 0" ≠ "bill to 0"; TB-scale data incurs fixed storage spend. ③ Billing breakdown details: compute (RCU/PCU) + storage (GB/hour) + add-ons (read-only nodes, SQL auditing, cross-region backup, backup overage) are billed separately; subscription doesn't cover read-only nodes and backup overage (community billing pitfall articles). On the RDS side there's a rule that "storage plans can't offset Serverless storage" — whether the same applies to PolarDB Serverless — 待验证.
• Selection implication: before selecting, draw the 24-hour load curve: peak-to-average ratio < 2 → go subscription directly; only talk Serverless with real valleys. Also confirm auto-pause conditions and long-connection behavior — otherwise a "Serverless" instance becomes the most expensive 7×24 pay-as-you-go form. Model storage charges separately — for large data volumes, storage charges can exceed compute charges.
• Sources: RCU/PCU billing units and 0–8 PCU, Scale to Zero — official help center 官方文档; MySQL Serverless auto start/stop, only storage billed when paused — community billing breakdown tutorials 社区实测; subscription vs pay-as-you-go selection advice — community billing articles 社区共识; auto-pause trigger conditions, storage-plan offset rules — not found in public docs 待验证

Deep dive 5 (regions & compliance): China-site vs international-site differences — POC must run on the target site and target region

• Mechanism: Alibaba Cloud's China site and international site (alibabacloud.com) are two separate account systems, region sets, and compliance frameworks; PolarDB's available regions, feature-release cadence, and support systems don't fully align between the two.
• Pushed to the edge: ① Version/feature time gaps: new features and engine versions usually launch on the China site first, the international site lags (e.g., the 2026 new forms like PG Agentic Database and nimble Serverless debuted in the China-site doc system); international-site docs have visibly lagging versions (e.g., the Oracle-compatibility English developer guide is stuck at a 2022 document version) (official docs version stamps, fact). ② Feature and region differences (fact): PolarDB-O 2.0 is available on the international site with DTS migration assessment support; the officially listed supported regions are Hangzhou/Shanghai/Shenzhen/Beijing/Zhangjiakou/Wulanchabu/Chengdu/Hong Kong/Tokyo/Singapore/Jakarta/US-West/US-East — Europe/US region coverage is clearly less than the China site (official international-site docs). The international site also has PolarDB promotional specs (e.g., polar.o.x4.large first month $1, official campaign page). Whether enterprise-edition custom kernels (e.g., PG 14-based PolarDB-O) and some compliance capabilities (MLPS/level-protection related) are offered on the international site is 待验证. ③ SLA/support response: international-site tickets get English-language support with timezone response gaps; the China site has Chinese phone/DingTalk/service-partner ecosystems, and troubleshooting articles and field-test cases are almost all in Chinese-language contexts 社区共识. Specific SLA number differences between the two sites' docs are 待验证 — neither side's SLA should be cited as contractual basis without legal review. ④ Data crossing borders & compliance: China's Data Security Law Article 31 requires compliance assessment for data leaving the country; China-site and international-site data cannot be directly interconnected — cross-border sync requires DTS/dedicated lines plus compliance review (community consensus + public regulatory common knowledge). A common pitfall for overseas-expanding teams: building PolarDB on a China-site account then discovering it can't be "copied" to the international site — it must be rebuilt + migrated; the international site bills in USD, with different subscription discount systems and voucher ecosystems than the China site — cost models must be recalculated; Chinese-language troubleshooting materials are partially inapplicable to international-site scenarios (e.g., compliance/filing-related sections).
• Selection implication: for overseas-expanding teams, the POC must open real instances on the target site's target region to verify feature availability — China-site conclusions can't be carried over. Put compliance review first: data-sovereignty ownership determines China-site vs international-site choice, and once made, migration cost is extremely high.
• Sources: international-site region support list — official international-site docs 官方文档; English docs version lag — doc version stamps 官方文档; PolarDB-O international-site specs and promotions — official campaign page 官方文档; account-system isolation and cross-border compliance — community consensus + public regulatory information; SLA/support-response number differences, enterprise-edition feature availability on the international site 待验证

1. Second-level read-node scale-out, adding read capacity moves no data (MySQL / PG)
   • Why it's true: under compute-storage separation, read-only nodes mount the same PolarStore shared storage and catch up with the primary via redo physical replication — no "full data copy" phase like adding an RDS replica. Official statement: adding a read-only node takes ~5 minutes; community field tests and user cases widely recognize "read-node addition significantly faster" as a genuine mechanistic dividend.
   • Edges and limits: ① "Second/minute-level" is node startup and going live, not traffic taking effect — the official FAQ confirms: read/write-splitting connections established before a new read-only node is added will not automatically forward requests to the new node; they must be dropped and rebuilt; ② under write intensity, redo generation speed exceeds read-only node replay speed and lag blows up from millisecond-level; ③ each read-only node is an independently billed compute node; ④ adding read-only nodes only scales reads — the write-throughput ceiling is always the single primary.
   • Sources: Alibaba Cloud official FAQ 官方文档; community consensus (CSDN/Juejin selection posts, 2026). Observed versions: PolarDB for MySQL 8.0, PolarDB-PG 14/15/16
2. PolarProxy builds read/write splitting and connection pooling into the infrastructure (strongest reputation on the PG edition)
   • Why it's true: the mandatory proxy (cluster endpoint) automatically does read/write splitting and consistency-level routing, with statement-level connection multiplexing on the PG edition. Real user load-test records: under equal pressure native PG memory hit 80%+ while PolarDB-PG stayed under 60% — the proxy absorbing connection storms, equivalent to a tuned pgbouncer + read/write-splitting middleware for free.
   • Edges and limits: ① The proxy is on the mandatory path for all traffic — one extra network hop, and proxy failures/mis-routed queries are a single-point risk; ② it disrupts DBA operational habits: pg_stat_activity shows proxy backend connections, so killing connections and locating slow SQL both require distinguishing "connected to proxy" vs "connected directly to node" — some users were forced to build two sets: "ops proxy" + "app proxy"; ③ the proxy's SQL parsing has boundaries — special protocol features / large-object scenarios may need to bypass the proxy and connect directly (details to-be-verified).
   • Sources: CSDN liuhuayang's Kill connections on PolarDB for PG migration series (2025, real migration records); CSDN load-test comparisons (2025). Observed versions: PolarDB for PostgreSQL 14 (mechanism applies to all versions)
3. Snapshot backup system: second-level backups, mandatory Level-1 backups (MySQL/PG)
   • Why it's true: based on storage-layer ROW snapshots, Level-1 backups copy no real data — second-level regardless of database size; official docs confirm "Level-1 backups are enabled by default and cannot be disabled". What users love is "not having to worry about backups anymore".
   • Edges and limits: ① The backup feature is free, but backup storage space is billed (beyond the free quota) — "cannot be disabled" = forced storage spend; ② Level-1 backup retention is only 3–14 days (data backups configurable up to 730 days, shorter by default); long-term archiving relies on Level-2 backups (disabled by default); ③ when a Level-2 backup transfer fails, expired backups are deleted directly (verified in official docs); ④ recovery means "restore into a new cluster", not in-place rollback.
   • Sources: Alibaba Cloud official Backup and Recovery docs; community consensus. Observed versions: MySQL / PG Cluster edition all versions
4. Serverless elasticity: "pay for what you use" for tidal businesses (MySQL edition + PG nimble Serverless)
   • Why it's true: compute (PCU) billed per second and settled hourly + storage by actual usage, scaling down to 0–1 PCU when idle. Compared to RDS's "buy specs on subscription", businesses with clear peaks and valleys avoid paying for peak capacity.
   • Edges and limits: ① Elasticity lags: load detection + spin-up is second-level, not instant — the first tens of seconds of a sudden spike may get throttled; ② each form has PCU lower/upper bounds (e.g., 0–8 PCU); ③ steady-load businesses may pay more than subscription, and unpredictable bills are a genuine finance-side complaint; ④ small-team selection-post consensus: teams too small to fully use PolarDB's features find RDS more worry-free.
   • Sources: official PolarDB-PG form-comparison docs (2026); CSDN selection posts (2025). Observed versions: MySQL Serverless, PG nimble Serverless (2026)
5. Oracle compatibility mode: a migration springboard for de-Oracle cost reduction (PolarDB-O / PG ora mode)
   • Why it's true: the same PG kernel provides Oracle syntax compatibility via compatibility mode, with a vendor statement of "95%+ Oracle SQL/PLSQL compatibility". Compared to RDS (no Oracle compatibility) and self-hosted PG, this is one of the lower-cost "Oracle license removal" paths within the Alibaba Cloud ecosystem — genuinely attractive to government/enterprise users bound by Oracle licenses.
   • Edges and limits: ① 95% is a vendor statement — the remaining 5% is usually stored-procedure packages and advanced features — packages like UTL_FILE need adjustments, and admin command and system view names differ from native Oracle (official developer community FAQ); ② the compatibility mode is chosen at installation time — switching later is costly; choosing the wrong mode = rebuild; ③ systems with heavy Oracle dependencies (complex PL/SQL, DB Jobs) still need item-by-item POCs — "zero code changes" is marketing speak; the reality is "fewer code changes".
   • Sources: Alibaba Cloud developer community FAQ (2026); official Oracle Compatibility User Guide PDF. Observed versions: PolarDB for PostgreSQL (Oracle compatibility mode)

• One-sentence positioning: For teams that want the Aurora-track "compute-storage separation + single-writer/multi-reader" but whose business lives in the Alibaba Cloud ecosystem and needs Chinese-language support and domestic compliance, PolarDB is the most natural choice today — but you must accept the fact that it's a closed-source managed service: the single-primary write ceiling, the proxy cognitive cost, and versioning following Alibaba Cloud's cadence — none of them can be avoided.
• Good for: businesses deeply invested in Alibaba Cloud (RDS→PolarDB one-click upgrade is the cheapest path); write-heavy/multi-reader OLTP with strong read-scaling needs; tidal businesses with clear peaks and valleys (Serverless PCU model); government/enterprise users bound by Oracle licensing fees using PolarDB-O as a de-Oracle springboard (item-by-item POCs first); teams wanting PG ecosystem + out-of-the-box connection pooling/read-write splitting.
• Not for: non-Alibaba Cloud / multi-cloud environments (MySQL and Oracle editions closed-source, only available on Alibaba Cloud); write-intensive businesses needing horizontal write scaling (single-primary is the architectural original sin — adding read-only nodes doesn't help, only primary spec upgrades or PolarDB-X); DBA teams heavily dependent on MySQL advanced features / native ecosystem tools (pt-osc, etc.); budget-sensitive small businesses (costs more than RDS at equivalent specs; paying for unused features = reverse payment, "start with RDS"); teams requiring immediate tracking of the latest PG major versions (PG 18 needs allowlist, versions follow Alibaba Cloud's cadence); overseas teams primarily serving Europe/US regions (international-site region coverage and feature cadence lag).
• Migration cost: RDS MySQL/PG → Low (one-click upgrade/DTS, supports rollback, downtime <10 minutes per official statement, community-tested cross-version one-click migration works); self-hosted MySQL/PG → Low–Medium (highly protocol-compatible, DTS full+incremental; watch driver versions, pt-osc and other ecosystem tool limits, and audit the app's transaction stickiness that can silently defeat read/write splitting); Oracle → Medium (PolarDB-O compatibility mode is "fewer code changes", not "zero code changes": autonomous transactions, DATE types, DBLINK, partitioned global indexes each need POCs; the compatibility mode is chosen at installation — wrong choice = rebuild).

PolarDB-X (cloud-native distributed database, formerly branded DRDS, open-sourced October 2021) is a distributed shared-nothing + compute-storage separation track product compatible with the MySQL protocol, focused on horizontal sharding and distributed transactions; PolarDB for MySQL/PostgreSQL/Oracle is the centralized shared-storage single-writer/multi-reader track — the two take different architectural routes, complementary rather than substitutes.

• Official docs: help.aliyun.com/polardb three-engine doc system (TDE/SSL APIs, backup & recovery, FAQ, billing docs, PolarDB-PG form comparison 2026); official international-site docs (PolarDB-O 2.0 region list, Oracle-compatibility English developer guide PDF); official TPC-C technical deep-dive (PolarStore anti-jitter design); official campaign page (international-site promotional specs)
• Open-source repos: polardb/polardb-for-postgresql (POLARDB_17_STABLE branch), polardb/polardbx issues
• Community-tested: CSDN liuhuayang's RDS→PolarDB-PG migration trilogy (2025); koharachan's PolarFlex lightweight-edition independent field test + security audit (2026-08, kernel 14.20); maos-runtime project onboarding field test (2026-08-30, PostgreSQL 16.14 (PolarDB 16.14.20.0), 189 extensions); Pigsty PolarDB-O deployment records (2026-08); PolarDB PG 16.14.20.0 + pgvector 0.8.3.1 smoke test (2026-08-30)
• Community consensus: CSDN/Juejin selection posts (2026); V2EX had no valuable in-depth discussion; Zhihu mostly vendor advertorials (not used)
• Next review: track official-statement changes on in-place major version upgrades, PG 18 GA progress, Serverless auto-pause terms, international-site feature alignment, MySQL kernel open-source status