In Serverless mode, AnalyticDB for PostgreSQL provides features such as separation of computing and storage resources, elastic scaling within seconds, and real-time data sharing across instances. These features are implemented based on the resource pooling and massive storage capabilities of cloud infrastructures and massively parallel processing (MPP), online and offline data processing, and Serverless technologies.
In Serverless mode, AnalyticDB for PostgreSQL decouples computing and storage resources so that they can be scaled with different proportions. Storage resources remain billed on a pay-as-you-go basis, but computing capabilities can be independently scaled to meet business requirements. This reduces storage costs and improves efficiency.
AnalyticDB for PostgreSQL in Serverless mode provides the following advantages over AnalyticDB for PostgreSQL in elastic storage mode:
- Reduces storage costs and enables on-demand resource use. You can use AnalyticDB for PostgreSQL in Serverless mode to implement cost-effective data analysis without the need to migrate your data to other storage media. This mode meets the data analysis requirements of the finance and Internet industries.
- Optimizes high-throughput writes and high-performance batch processing operations with elastic scaling to suit the scenarios in which large amounts of data and large traffic fluctuations are involved.
- Provides the data sharing feature based on the separation of storage and computing resources. Shared data can be accessed from other databases without the need of data export and import. It is easier and more cost-effective than data access in traditional data warehouses.
AnalyticDB for PostgreSQL in Serverless mode is supported in the following regions and zones:
- China (Beijing): Zone H and Zone I
- China (Hangzhou): Zone I and Zone J
- China (Shanghai): Zone G and Zone F
- China (Zhangjiakou): Zone C
- China (Shenzhen): Zone E and Zone F
- Asia Pacific
Singapore (Singapore): Zone A and Zone C
- Europe & Americas
US (Virginia): Zone A
Comparison of service modes
The Serverless mode supports most features of the elastic storage mode. The following table describes the differences between these two service modes.
|Category||Feature||Elastic storage mode||Serverless mode|
|Instance management||Basic instance information||Supported||Supported|
|Logon to databases by using Data Management (DMS)||Supported||Supported|
|Instance configuration upgrade or downgrade||Supported||Not supported|
|Coordinator node addition or removal||Supported||Supported|
|Instance scale-in||Not supported||Supported|
|Minor version update||Supported||Supported|
|Account management||Account creation||Supported||Supported|
|Database connection||Basic connection information||Supported||Supported|
|Public endpoint application||Supported||Supported|
|Monitoring and alerting||Monitoring||Supported||Supported|
|Backup and restoration||Supported||Supported|
The Serverless mode supports more than 95% of features of the elastic storage mode. In most cases, the same syntax can be used for both the Serverless and elastic storage modes. Tools such as the JDBC connector, ODBC connector, and psql can be used in Serverless mode in the same way as they are used in elastic storage mode. The following table describes the limits of AnalyticDB for PostgreSQL in Serverless mode on specific features.
|Basic features||ALTER TABLE||
|Primary keys||Not supported|
|Unique constraints||Not supported|
|INSERT ON CONFLICT||Not supported|
|Table unlogging||Not supported|
|Heap tables, append-optimized row-oriented tables, and append-optimized column-oriented tables||Not supported|
|Custom data types||Not supported|
|Compute engines||ORCA optimizer||Supported|
|Transaction isolation levels||Read Committed and Repeatable Read are supported.|
|Advanced features||Backup and restoration||Supported|
You can migrate data from an AnalyticDB for PostgreSQL instance in elastic or reserved storage mode to an instance in Serverless mode. For more information, see Migrate data from an AnalyticDB for PostgreSQL instance in elastic or reserved storage mode to an instance in Serverless mode.
The following table describes the support of the Serverless mode for different data migration types.
Instances in Serverless mode can be scaled within minutes. The following scaling performance is provided for reference:
- An instance that has 16 or fewer compute nodes can be scaled within 60 seconds.
- An instance that has more than 16 compute nodes can be scaled within 5 minutes.
You can use the elastic scaling capability of AnalyticDB for PostgreSQL in Serverless mode to scale out compute nodes before expected peak periods such as Double 11 and then scale in compute nodes after the peak hours. AnalyticDB for PostgreSQL is billed on an hourly basis based on the actual duration of resource use and compute node specifications. This way, you can minimize costs while ensuring the service performance.
In Serverless mode, each compute node has a maximum storage capacity. Before you scale in compute nodes, make sure that the total amount of data does not exceed the maximum storage capacity of all the remaining compute nodes combined. For example, assume that each compute node provides 2 cores, 8 GB memory, and a maximum of 960 GB storage capacity. If you want to scale in your instance to four compute nodes, the total amount of data cannot exceed 3,840 GB (960 GB × 4).
The following table describes the maximum storage capacity of different compute node specifications in AnalyticDB for PostgreSQL in Serverless mode.
|Specifications||Maximum storage capacity|
|2 cores, 8 GB memory||960 GB|
|4 cores, 16 GB memory||2,200 GB|
|8 cores, 32 GB memory||5,400 GB|
|16 cores, 64 GB memory||11,800 GB|
Except during service interruptions that occur before and after scaling, workloads remain readable and writable during the scaling process.
Data sharing (beta)
Compared with the data import and export method used in traditional data warehouses, data sharing used in AnalyticDB for PostgreSQL in Serverless mode has the following advantages:
- Reduced storage costs: Data replication or migration is not needed across AnalyticDB for PostgreSQL instances. Only a single copy of data is stored in the distributed storage and can be shared by multiple instances within the specified range. This way, less storage space is required.
- Ease of use: After you create a share on a producer instance, perform authorization, and then import data to the share, you can access the shared data on a consumer instance in the same manner as you would access data on the producer instance. The table schema does not need to be migrated. The addition or removal of shared objects and authorization changes can be automatically synchronized to the consumer instance.
- Data consistency: Consumer instances can access the shared data with capabilities approximate to those of producer instances. In addition, consumer instances can read the latest written data of producer instances. This ensures the atomicity, consistency, isolation, durability (ACID) capabilities of transactions.
Data sharing can help you resolve the following issues:
- Isolation between complex organization permissions: For example, assume that an instance is created in the corporate headquarters and another instance is created in a branch. Data sharing can be used to allow the instance in the branch to access specific data of the instance in the corporate headquarters.
- Isolation between complex business resources: For example, assume that physical resources are isolated between the extract, transform, load (ETL) and ad hoc business types. Data sharing can be used to share ETL results among instances that involve ad hoc queries.
- Failure on cross-business collaboration: For example, if the same copy of data needs to be analyzed by R&D, sales, operations, and financial personnel, data sharing can be used to allow data access by different business groups within an organization.
Data sharing is in beta testing and has the following limits:
- Data sharing is supported on standard tables. It is not supported on partitioned tables, external tables, views, schemas, or functions.
- Data sharing is supported on hash distributed tables. It is not supported on replicated tables or random tables.
- Data sharing is not supported on subtransactions.
- If multiple shares exist in a producer instance, a consumer instance can subscribe only to one of the shares.
- DDL operations are not allowed on shared tables. To perform DDL operations on a shared table, you must disable sharing for the table.