How to choose instance types?
AnalyticDB for PostgreSQL offers two instance modes — elastic storage mode and Serverless mode. The right choice depends on your workload characteristics, scaling needs, and operational preferences.
Instance modes at a glance
| Dimension | Elastic storage mode | Serverless mode |
|---|---|---|
| Architecture | Integrated computing and storage | Decoupled computing and storage |
| Scaling | Manual: change node specs or add nodes | Within seconds; on-demand storage |
| Best for | Stable, predictable workloads | Variable or bursty workloads |
| High availability | High-availability Edition available | High-availability Edition |
| Storage type | ESSD (PL0–PL2) | Shared storage |
| Parameters to set | Edition, Compute Node Specifications, Nodes, Storage Disk Type, Single Node Storage Capacity | Edition, Compute Node Specifications, Nodes |
Default recommendation: Start with elastic storage mode. It provides comprehensive features — including hybrid transactional and analytical processing (HTAP), data lake analysis, spatio-temporal analysis via PostGIS and GanosBase, and workload management through resource queues — making it the right fit for most production workloads.
Choose elastic storage mode
Choose elastic storage mode when any of the following apply:
-
Your workload is stable or grows predictably over time.
-
You need spatio-temporal analysis (PostGIS, GanosBase) or semi-structured data support (JSON, Parquet, Avro).
-
You are migrating from Greenplum, Teradata, Oracle, or Db2 and need broad ecosystem compatibility.
-
You need enterprise-class workload management with user-defined functions or resource queues.
-
You process extract-transform-load (ETL) pipelines from sources like ApsaraDB RDS, Realtime Compute for Apache Flink, or OSS.
Recommended starting configuration: High-availability Edition, 4 cores and 32 GB per compute node, more than four compute nodes.
The High-availability Edition provides built-in redundancy. High-performance Edition (Basic Edition) does not provide high availability — use it only for proof of concept (POC) testing or development environments, not for production.
Choose Serverless mode
Choose Serverless mode when any of the following apply:
-
Resource requirements fluctuate significantly across time frames (for example, heavy batch jobs at night and light queries during the day).
-
You have not yet finalized resource plans for a new project.
-
You need isolated resources for distinct business units and want to track usage per unit in billing.
-
You need data sharing across multiple instances without the risk of data silos.
Recommended starting configuration: 4 cores and 16 GB per compute node, more than four compute nodes.
Serverless mode supports automatic scheduling (currently in invitational preview). In automatic scheduling mode, capacity is expressed in AnalyticDB compute units (ACUs) rather than fixed node specs, ranging from 8 to 32 ACUs. To apply for invitational preview, submit a ticket.
Choose node specifications
After selecting a mode, choose your compute node specifications based on query complexity and data volume:
| Specification | Disk type | When to use |
|---|---|---|
| 2 cores, 16 GB | PL0 ESSD | POC testing, individual learning, feature trials |
| 4 cores, 32 GB | PL0 or PL1 ESSD | Balanced computing and storage — the most common choice |
| 8 cores, 64 GB | PL1 ESSD | Compute-intensive workloads with complex queries or high concurrency |
| 16 cores, 128 GB | PL2 ESSD | Enterprise-class platforms with large volumes of concurrent queries on core data |
The specifications above apply to High-availability Edition. High-performance Edition (Basic Edition) uses different memory ratios (2c/8 GB, 4c/16 GB, 8c/32 GB, 16c/64 GB). See the full specification tables below.
Larger node specifications improve query performance for complex, large-scale queries. However, larger is not necessarily faster for simple or small queries — and it costs more. For high concurrency (many simultaneous queries), add more compute nodes instead of scaling up individual node specs.
Choose the number of compute nodes
Node count controls parallelism and fault tolerance. Use these two scaling strategies independently — they solve different problems:
-
Scale up (larger node specs): Use when individual queries run slowly due to data volume or complexity.
-
Scale out (add nodes): Use when queries queue up due to high concurrency. With at least two nodes, AnalyticDB for PostgreSQL mirrors data across nodes to reduce the risk of data loss.
Minimum for production: More than four compute nodes.
Common scenarios
Migrate from on-premises or self-managed databases
Scenario: Moving data from Greenplum, Teradata, Oracle, or Db2 to the cloud.
Choose: Elastic storage mode, High-availability Edition or High-performance Edition (Basic Edition) based on your business requirements, 4 cores and 32 GB per compute node, more than four compute nodes.
AnalyticDB for PostgreSQL is compatible with Greenplum and PostgreSQL ecosystems, enabling seamless data migration. After migration, adjust resources based on actual business requirements.
Build a data platform for SaaS applications
Scenario: Building a stable data platform that ingests from multiple sources, supports ETL, HTAP workloads, business intelligence (BI) reports, and enterprise data services.
Choose: Elastic storage mode, High-availability Edition, 4 cores and 32 GB per compute node, more than four compute nodes.
Elastic storage mode supports data import from Alibaba Cloud services and third-party sources. It provides massively parallel processing (MPP)-based computing performance and node scaling as workloads grow.
Analyze spatio-temporal or autonomous driving data
Scenario: Processing vehicle-collected data with geographic and time series analysis, JSON compatibility, and feature engineering for business dashboards.
Choose: Elastic storage mode, High-performance Edition (Basic Edition), 4 cores and 32 GB per compute node.
Elastic storage mode supports PostGIS and GanosBase for spatio-temporal analysis, accelerated queries in MPP architecture, and flexible analysis on semi-structured data including JSON.
High-performance Edition (Basic Edition) does not provide high availability. If your workload requires high uptime, use High-availability Edition instead.
Handle bursty or fluctuating workloads
Scenario: A data platform where resource demand varies significantly — such as gaming or large-scale internet operations with heavy log cleansing, user behavior analysis, and business-hours resource isolation.
Choose: Serverless mode, 4 cores and 16 GB per compute node, more than four compute nodes.
Serverless mode adjusts resources flexibly across time frames. It provides an efficient Simple Log Service + OSS solution for log data cleansing and supports HTAP workloads with business-hours resource isolation.
Isolate resources across business units
Scenario: Multiple independent business units each with separate workloads, where you need to prevent data silos and track resource usage per unit.
Choose: Serverless mode, 4 cores and 16 GB per compute node, more than two compute nodes. Deploy multiple instances.
Serverless mode supports data sharing across instances — shared data from production can be consumed by development instances, keeping development current without affecting production. Each instance fully isolates resources, so you can read separate resource usage per business unit from the bill.
Elastic storage mode specifications
Table 1. Elastic storage mode
| Edition | Node specifications | Recommended disk type | Suitable scenario |
|---|---|---|---|
| High-availability Edition | 2 cores, 16 GB | PL0 ESSD | POC testing, individual learning, feature trials |
| 4 cores, 32 GB | PL0 or PL1 ESSD | Balanced computing and storage — chosen by 60% of users | |
| 8 cores, 64 GB | PL1 ESSD | Compute-intensive scenarios with complex data analysis or high concurrency | |
| 16 cores, 128 GB | PL2 ESSD | Enterprise-class platforms with large volumes of concurrent queries on core data | |
| High-performance Edition (Basic Edition) | 2 cores, 8 GB | PL0 ESSD | POC testing, individual learning, feature trials |
| 4 cores, 16 GB | PL0 or PL1 ESSD | Balanced computing and storage for batch data analysis | |
| 8 cores, 32 GB | PL1 ESSD | ||
| 16 cores, 64 GB | PL2 ESSD |
High-performance Edition (Basic Edition) does not provide high availability. Proceed with caution when using it for production workloads.
Serverless mode specifications
Table 2. Serverless mode
| Edition | Scheduling mode | Node specifications or ACUs | Disk type | Suitable scenario |
|---|---|---|---|---|
| High-availability Edition | Manual scheduling | 4 cores, 16 GB | Shared storage | Resource requirements fluctuate significantly; resource plans are not yet defined; workloads are distinctly isolated across business units |
| 8 cores, 32 GB | Shared storage | |||
| Automatic scheduling (invitational preview) | 8–32 ACUs | Shared storage |
What's next
-
Instance specifications — full specification tables and detailed case recommendations