PolarDB for PostgreSQL is available in two editions: Enterprise Edition and Standard Edition. Both share the same core architecture and cover the full range of features across cluster management, scaling, high availability, security, monitoring, and AI. The key differences are in compute infrastructure, Serverless configuration, and maximum read-only node count. Enterprise Edition is built for workloads that need dedicated physical compute (no virtualization overhead) or more than 7 read-only nodes. Standard Edition suits the majority of production workloads and adds support for the Yitian ARM architecture and fully managed Serverless clusters.
Feature comparison
The main performance difference between the two editions comes from the compute layer. Enterprise Edition runs compute nodes on dedicated physical machines, eliminating virtualization overhead. Standard Edition runs compute nodes on Elastic Compute Service (ECS) instances. For storage-layer performance differences, see the performance comparison for maximum QPS benchmarks.
Feature availability may depend on prerequisites beyond the edition. For example, Serverless clusters (billing type: Serverless) support only PostgreSQL 14. See each feature's documentation for specific prerequisites.
| Category | Feature | Description | Enterprise Edition | Standard Edition |
|---|---|---|---|---|
| Cluster management | x86 architecture | Built with Intel processors and a high-performance network for demanding enterprise workloads. | Supported | Supported |
| Yitian ARM architecture | Uses Alibaba Cloud's self-developed Yitian 710 processor and 25 GE high-speed smart NICs. | Not supported | Supported | |
| Single-writer, multi-reader cluster | One Primary Node handles read and write requests; read-only nodes handle read-only requests. Automatic failover between the Primary Node and read-only nodes provides High Availability (HA). Enterprise Edition supports up to 15 read-only nodes; Standard Edition supports up to 7. | Up to 15 read-only nodes | Up to 7 read-only nodes | |
| Cluster Recycle Bin | Stores released PolarDB clusters so you can restore them to a new cluster or delete their backup sets. | Supported | Supported | |
| Parameter management | Modify cluster and node parameters in the console after cluster creation. | Supported | Supported | |
| Minor version management | Upgrade the database proxy (Proxy), database kernel (DB), or distributed storage layer (Store) independently or together. | Supported | Supported | |
| Network channels | Access data across databases using Foreign Data Wrapper (FDW) external tables and dblink. | Supported | Supported | |
| Auto Scaling | Add or remove nodes | Manually add read-only nodes with the desired specifications or remove unneeded ones after cluster creation. | Supported | Supported |
| Change specifications | Scale compute resources vertically (up/down) or horizontally (out/in), and scale storage horizontally — all online with no downtime. Changes take effect within minutes. | Supported | Supported | |
| Serverless clusters | Fully managed auto-scaling: nodes scale up within seconds during traffic spikes and scale down automatically during low-load periods. Requires billing type Serverless (PostgreSQL 14 only). | Not supported | Supported | |
| Serverless capabilities for fixed-specification clusters | Adds dynamic elastic scaling to clusters with a fixed specification and a Subscription or Pay-as-you-go billing method. Nodes scale up within seconds during traffic spikes and scale down automatically during low load. Unlike Serverless clusters, the cluster specification and billing method are predefined. | Supported | Not supported | |
| High performance | In-Memory Column Index (IMCI) | A columnar index that complements the native PostgreSQL execution engine, retaining OLTP performance while significantly improving complex query performance. | Supported | Supported |
| Optimizers | Multiple query optimization techniques: subquery unnesting, plan freezing, cost-based transformations, OR-to-UNION ALL conversion, and sublink pushdown. | Supported | Supported | |
| Partitioned tables | Fully compatible with native PostgreSQL partitioning syntax, with enhanced performance and a broader set of partitioning types for managing large tables. | Supported | Supported | |
| Multi-tenancy | Tenant-level resource isolation by limiting resources used by one or more processes. | Supported | Supported | |
| Table size caching (RSC) | Caches table block counts in shared memory, reducing file system calls and accelerating SQL execution. | Supported | Supported | |
| Garbage collection during off-peak hours | Proactive garbage collection during a configured maintenance window, reducing autovacuum load during peak hours and freeing resources for business traffic. | Supported | Supported | |
| Global Plan Cache (GPC) | Shares execution plan cache across connections. Reduces memory usage and Out of Memory (OOM) risk for workloads with many distinct SQL statements, and lowers plan generation overhead. | Supported | Supported | |
| Global Cache | Metadata caches in shared memory shared by all processes, improving memory utilization and reducing OOM risk. | Supported | Supported | |
| Backup and restore | Backup | Supports data backups (full backups) and physical log backups (incremental backups). Combining a full backup with subsequent redo log backups enables point-in-time restore for a full cluster or individual databases and tables. Enterprise Edition stores data backups on PolarDB distributed storage system; Standard Edition stores them locally. | Supported | Supported |
| Restore | Restores a full cluster, a single database, or a single table from a backup set or to a specific point in time. Restored databases or tables are created as new objects in the original cluster — existing data is not overwritten. | Supported | Supported | |
| High availability | Single-zone HA | The multi-node architecture provides automatic failover from the Primary Node to a read-only node if a failure occurs. | Supported | Supported |
| Multi-zone HA | Clusters that span multiple Availability Zones (AZs) for data center-level disaster recovery, beyond what single-AZ clusters provide. | Supported | Supported | |
| High Security | Account management | Manage console accounts and database accounts. | Supported | Supported |
| IP whitelist | Restrict cluster access to specific IP addresses or ECS instances in a security group. | Supported | Supported | |
| SSL encryption | Encrypts network connections at the transport layer using Secure Sockets Layer (SSL) to improve data security and integrity. | Supported | Supported | |
| Transparent Data Encryption (TDE) | Real-time I/O encryption and decryption of data files. Data is encrypted before being written to disk and decrypted when read into memory, with no change to data file size or application code. | Supported | Supported | |
| SQL throttling | Configure throttling rules based on endpoints to prevent abnormal SQL traffic from affecting your workload. | Supported | Supported | |
| Always-Encrypted Database | Client-side encryption before data is sent to the database server, so plaintext is never visible to the server. Provides end-to-end data security. | Supported | Supported | |
| Connection management | Transaction-level Connection Pooling | Shares database connections at the transaction level to reduce load from large numbers of concurrent connections. | Supported | Supported |
| Global Consistency | Three consistency levels to match different workload requirements: eventual consistency, session consistency, and global consistency. | Supported | Supported | |
| Extension management | Extensions | A broad set of extensions that expand database functionality — heterogeneous data access, similarity calculations, full-text search, and more. | Supported | Supported |
| Ganos Spatiotemporal Engine | Ganos Spatiotemporal Engine | Integrated capabilities for storing, querying, analyzing, and rendering spatiotemporal, multi-modal, and polymorphic data. Used in urban management, logistics, shared mobility, natural resources, aerospace, and IoT. | Supported | Supported |
| Cost-effectiveness | Tiered storage for hot/cold data | Moves infrequently accessed data to lower-cost storage media such as OSS to reduce storage costs. | Supported | Supported |
| Monitoring and optimization | Performance monitoring | Rich performance metrics with second-level monitoring frequency for tracking cluster health and diagnosing issues. | Supported | Supported |
| Quick diagnostics | Session management, real-time performance monitoring, space analysis, and Performance Insights — integrated from Database Autonomy Service (DAS). | Supported | Supported | |
| Slow SQL queries | View slow query trends and statistics, with SQL suggestions and diagnostic analysis. | Supported | Supported | |
| SQL Explorer and Audit | Full request logging and security auditing with search, SQL insights, security audit, traffic playback, and stress testing — provided by DAS. | Supported | Supported | |
| PolarDB for AI | PolarDB for AI | Polar_AI is an AI extension that integrates advanced AI models directly into PolarDB, enabling machine learning and natural language processing within the database. | Supported | Supported |
| Data migration and synchronization | One-click migration from RDS | Migrate from an RDS database to PolarDB with one click while preserving the original endpoint. | Supported | Supported |
| Migrate to cloud | Migrate self-managed PostgreSQL databases to PolarDB for PostgreSQL. | Supported | Supported |