AnalyticDB for PostgreSQL offers two resource types—elastic storage mode and Serverless mode—each optimized for different workload patterns. This page explains how each mode scales, what specifications are available, and which configuration to start with for your scenario.
How scaling works
Understanding the scaling model helps you choose the right starting configuration and know when to adjust it.
Adding compute nodes increases query concurrency and distributed processing capacity. Use this when multiple concurrent queries are competing for resources.
Upgrading node specifications (more CPU and memory per node) improves single-query performance and handles larger in-memory datasets. Use this when individual queries are slow or memory-intensive.
Scaling storage (elastic storage mode only) is independent of compute scaling—you can expand storage without changing node count or specifications.
In Serverless mode, the service manages compute resources automatically (when automatic scheduling is available) or lets you change node specifications on demand without reprovisioning.
Choose a mode
| Elastic storage mode | Serverless mode | |
|---|---|---|
| Architecture | Integrated computing and storage | In-house decoupled computing and storage |
| Storage | Persistent per-node storage (ESSD) | Shared storage |
| Scaling | Change node specs, add nodes, or expand storage independently | Change node specs within seconds; automatic scaling in preview |
| Best for | Stable, predictable workloads; Greenplum/PostgreSQL migrations; enterprise data platforms | Fluctuating workloads; isolated business units; development environments |
When to use elastic storage mode
Choose elastic storage mode when:
Migrating from Greenplum, PostgreSQL, Teradata, Oracle, or Db2
Running extract-transform-load (ETL) pipelines with predictable daily volume
Building an enterprise data platform with hybrid transactional and analytical processing (HTAP) workloads
Requiring spatio-temporal analysis (PostGIS, GanosBase) or data lake integration
When to use Serverless mode
Choose Serverless mode when:
Resource demand spikes unpredictably (for example, gaming peak hours or retail campaigns)
Multiple business units need isolated compute but shared data
Setting up a data development environment that mirrors production data without impacting it
Resource plans are not yet defined
Elastic storage mode specifications
When purchasing an instance, specify Edition, Compute Node Specifications, Nodes, Storage Disk Type, and Single Node Storage Capacity.
Table 1. Elastic storage mode
| Edition | Node specifications | Recommended disk type | Suitable scenario |
|---|---|---|---|
| High-availability Edition | 2 cores, 16 GB | PL0 Enterprise SSD (ESSD) | Proof of concept (POC) testing, individual learning, or feature trials |
| High-availability Edition | 4 cores, 32 GB | PL0 ESSD or PL1 ESSD | Balanced computing and storage—the choice for 60% of users |
| High-availability Edition | 8 cores, 64 GB | PL1 ESSD | Compute-intensive workloads with large-scale complex queries or high concurrency |
| High-availability Edition | 16 cores, 128 GB | PL2 ESSD | Enterprise-class platforms with heavy concurrent access to core business data |
| High-performance Edition (Basic Edition) | 2 cores, 8 GB | PL0 ESSD | POC testing, individual learning, or feature trials |
| High-performance Edition (Basic Edition) | 4 cores, 16 GB | PL0 ESSD or PL1 ESSD | Balanced computing and storage for batch data analysis |
| High-performance Edition (Basic Edition) | 8 cores, 32 GB | PL1 ESSD | — |
| High-performance Edition (Basic Edition) | 16 cores, 64 GB | PL2 ESSD | — |
High-performance Edition (Basic Edition) does not provide high availability. Evaluate this carefully before using it for production workloads.
Starting point: For most new deployments, start with High-availability Edition, 4 cores and 32 GB, and at least 4 nodes. Monitor query latency and CPU utilization. If individual queries are slow, upgrade node specifications. If concurrent query throughput is the bottleneck, add more nodes.
Serverless mode specifications
When purchasing an instance, specify Edition, Compute Node Specifications, and Nodes.
Table 2. Serverless mode
| Edition | Scheduling mode | Node specifications or ACUs | Disk storage type | Suitable scenario |
|---|---|---|---|---|
| High-availability Edition | Manual scheduling | 4 cores, 16 GB | Shared storage | On-demand scaling, data sharing across instances, isolated business workloads, or undefined resource plans |
| High-availability Edition | Manual scheduling | 8 cores, 32 GB | Shared storage | Same as above, with higher per-node compute capacity |
| High-availability Edition | Automatic scheduling (invitational preview) | 8–32 AnalyticDB compute units (ACUs) | Shared storage | — |
Automatic scheduling is in invitational preview. To apply, submit a ticket.
Starting point: Start with 4 cores and 16 GB and at least 2 nodes. For workloads with significant concurrency spikes, use 4 or more nodes and monitor ACU utilization to determine whether to scale up.
Use cases
Internet and manufacturing: migrating from on-premises databases
Workload: Migrating data from self-managed databases or Greenplum data warehouses to the cloud.
Recommended mode: Elastic storage mode.
AnalyticDB for PostgreSQL is compatible with Greenplum, PostgreSQL, and the broader open source ecosystem, enabling seamless migration. After migration, adjust node count and specifications based on actual workload without re-architecting the data model.
SaaS platforms: building a stable data mid-end
Workload: ETL pipelines ingesting from ApsaraDB RDS, Realtime Compute for Apache Flink, and Object Storage Service (OSS); HTAP; BI reports; and enterprise data services.
Recommended mode: Elastic storage mode. Start with High-availability Edition, 4 cores and 32 GB or higher, and at least 4 nodes.
Elastic storage mode supports data import from Alibaba Cloud services and third-party sources, provides workload management through user-defined functions and resource queues, and delivers computing performance approximately 3 times that of traditional data warehouses.
Enterprise digital transformation: replacing legacy data warehouses
Workload: Replacing on-premises Teradata, Oracle, Db2, or Greenplum data warehouses.
Recommended mode: Elastic storage mode. Use High-availability Edition or Basic Edition based on your availability requirements. Start with 4 cores and 32 GB or higher and at least 4 nodes.
AnalyticDB for PostgreSQL has replaced Teradata and Oracle data warehouses across hundreds of financial institutions, internet service providers (ISPs), public sector organizations, and enterprises.
Autonomous driving: geospatial and time series analysis
Workload: Geospatial and time series analysis on vehicle-collected data; JSON and spatio-temporal data processing; business dashboards; feature engineering.
Recommended mode: Elastic storage mode, Basic Edition. Start with 4 cores and 32 GB or higher.
The PostGIS and GanosBase engines provide spatio-temporal analysis with massively parallel processing (MPP) acceleration. Semi-structured data such as JSON is supported natively, alongside data lake integration.
Internet gaming: user behavior analysis with resource isolation
Workload: User behavior data analysis, log cleansing and data joins, gaming operations support, HTAP with resource isolation during business hours.
Recommended mode: Serverless mode. Start with 4 cores and 16 GB and at least 4 nodes.
Serverless mode adjusts resources dynamically across time frames. The Log Service and OSS integration provides an efficient pipeline for log cleansing. Serverless mode also provides powerful analysis and single-node computing capabilities. A single instance can fully isolate resources, so business unit costs are visible separately in your bill.
New retail: building a customer data platform
Workload: Multi-source data ingestion, customer segmentation, and a customer data platform (CDP).
Recommended mode: Elastic storage mode. Use High-availability Edition or Basic Edition based on your availability requirements. Start with 4 cores and 32 GB or higher and at least 4 nodes.
Elastic storage mode supports JSON, CSV, Avro, and Parquet formats for data aggregation and tag generation. It integrates with Quick Audience for one-stop cloud-based customer platform construction.
Large-scale internet enterprises: independent business units with shared data
Workload: Multiple independent business mid-ends alongside a unified data mid-end; efficient resource deployment per unit; no data silos.
Recommended mode: Serverless mode. Start with 4 cores and 16 GB and at least 2 nodes. Deploy multiple instances as needed.
Serverless mode supports data sharing across multiple instances, eliminating data silos as business mid-ends evolve. Each instance provides full resource isolation, making per-unit billing straightforward.
Data development platforms: isolating development from production
Workload: Reducing the impact of development work on production; providing up-to-date data for development.
Recommended mode: Serverless mode. Start with 4 cores and 16 GB and at least 2 nodes. Deploy multiple instances as needed.
The data sharing feature lets development instances consume data shared by production instances in real time, keeping development environments current without putting load on production.