Introduction
AnalyticDB for PostgreSQL Serverless mode, with its cloud-native architecture, completely decouples computing from storage, addressing the issue of proportional scaling. It enables users to scale computing power quickly and independently during business fluctuations, while storage costs are based on a pay-as-you-go model. This flexibility allows for rapid adaptation to business changes and cost optimization, helping enterprises to reduce expenses and enhance efficiency.
Serverless mode offers several advantages over the elastic storage mode:
-
It significantly reduces storage costs and supports on-demand usage. Historical data does not need to be migrated to other storage media, simplifying data analysis and providing a cost-effective, efficient one-stop solution for the growing data analysis needs of industries such as finance and the Internet.
-
It optimizes high-throughput write scenarios and high-performance batch processing operations, offering elastic scaling capabilities suitable for large business data volumes and typical business access peaks and troughs.
-
It enables data sharing based on compute-storage separation, transcending the limitations of physical machines and facilitating data flow in the cloud. The one-write-multiple-read model eliminates the need for data import before access in traditional data warehouses, streamlining operations, enhancing efficiency, and reducing costs.
Precautions
Important
Currently, the international site only supports the creation of pay-as-you-go AnalyticDB for PostgreSQL Serverless mode instances.
The regions and zones that support the creation of AnalyticDB for PostgreSQL Serverless mode are as follows:
-
Asia Pacific:
-
Singapore: Singapore Zone C
-
Thailand (Bangkok): Bangkok Zone A
-
Japan (Tokyo): Tokyo Zone B
Comparison of service modes
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 |
Category | Feature | Elastic storage mode | Serverless mode |
Instance management | Basic instance information | Yes | Yes |
Logon to databases (DMS) | Yes | Yes |
Create instance | Yes | Yes |
Release instance | Yes | Yes |
Restart instance | Yes | Yes |
Instance configuration upgrade and downgrade | Yes | Not supported |
Addition or removal of coordinator nodes | Yes | Yes |
Scale out an instance | Yes | Yes |
Instance scale-in | Yes | Yes |
Minor version upgrade | Yes | Yes |
Account management | Create account | Yes | Yes |
Reset password | Yes | Yes |
Database connection | Basic connection information | Yes | Yes |
Apply for a public endpoint | Yes | Yes |
Monitoring and alerting | Monitor | Yes | Yes |
Alert rule | Yes | Yes |
Data security | Whitelist | Yes | Yes |
SQL audit | Yes | Yes |
SSL | Yes | Yes |
Backup and recovery | Yes | Yes |
Configuration | Parameter settings | Yes | Yes |
Features and constraints
Serverless mode supports over 95% of the features of the elastic storage mode. In most cases, the same syntax can be used for both modes. Tools such as the JDBC connector, ODBC connector, and psql can be used in Serverless mode just as in the elastic storage mode. The following table describes the limits of AnalyticDB for PostgreSQL in Serverless mode on specific features.
Important
-
In Serverless mode, the primary key and index features are in public preview. To create indexes, contact technical support to enable the index feature.
-
After indexes are created, the scaling performance is affected. The time required for scaling is proportional to the data volume of indexes.
-
Index storage incurs additional fees. There are no charges for index storage during the public preview.
Category | Feature | Constraints and description |
Category | Feature | Constraints and description |
Basic feature | ALTER TABLE | Most features of the ALTER TABLE statement are supported. For example, you can modify the table name, delete column constraints, and add or remove columns. The data type of columns or the distribution column cannot be modified.
|
Index | Yes |
PRIMARY KEY | Yes |
UNIQUE CONSTRAINT | Yes |
INSERT ON CONFLICT | Yes |
Table unlogging | No |
Trigger | Not supported |
Heap tables, append-optimized row-oriented (AORO) tables, and append-optimized column-oriented (AOCO) tables | No |
Custom data type | Not supported |
Explicit cursors | Yes |
Compute engine | ORCA optimizer | Yes |
Laser engine | Yes |
Transaction capabilities | Subtransactions | Yes |
Transaction isolation levels | Read committed (RC) and repeatable read (RR) isolation levels are supported. |
Advanced feature | Backup and recovery | Yes |
Materialized view | Yes |
AUTO VACUUM | Yes |
AUTO ANALYZE | Yes |
Expansion without service interruptions | Yes |
Elastic scale-in | Yes |
GIS/GANOS | No |
Data sharing | Yes |
Data migration
You can migrate existing data to the serverless pattern. For migrating AnalyticDB for PostgreSQL from the elastic storage pattern and reserved storage pattern to the serverless pattern, see data migration between AnalyticDB for PostgreSQL.
For more information about data migration support, see the following table.
Migration type | Document | Supported |
Automatic scheduling (in invitational preview)
Note
AnalyticDB for PostgreSQL Serverless automatic scheduling mode is in invitational preview. To use it, you can submit a ticket to request invitational preview qualification.
AnalyticDB for PostgreSQL Serverless automatic scheduling mode instances will automatically start and stop based on traffic awareness. If there is no traffic, the instance will automatically enter an idle state, during which no computing fees will be charged.
AnalyticDB for PostgreSQL Serverless automatic scheduling mode allows you to manually modify the Computing Resource Threshold and Idle Release Waiting Time. For more information, see 实例资源配置.
Serverless automatic scheduling mode instances are billed based on Analytic Compute Units (ACUs), which are the computing power units of Serverless automatic scheduling mode instances. Alibaba Cloud collects the number of used ACUs every hour and bills on a per-second basis, with hourly billing. For more pricing information, see 产品定价.
Elastic scaling
Serverless mode supports minute-level online elastic scaling. The following scaling performance is provided for reference:
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. The billing module of AnalyticDB for PostgreSQL will charge based on the actual application duration and specifications (on an hourly basis). 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, ensure that the total data volume does not exceed the maximum storage capacity of all the remaining compute nodes combined. For example, if each compute node provides 2 CPU cores, 8 GB of memory, and a maximum of 960 GB storage capacity, and you want to scale in your instance to four compute nodes, your total data volume 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.
Specification | Maximum storage capacity |
Specification | Maximum storage capacity |
2C8G | 960 GB |
4C16G | 2,200 GB |
8C32G | 5,400 GB |
16C64G | 11,800 GB |
During the scaling process, the workloads arestill readable and writable, except for brief service interruptions before and after scaling.
Data sharing (beta)
Data sharing in AnalyticDB for PostgreSQL Serverless mode offers several advantages over traditional data import and export methods:
-
Storage costs are reduced as there is no need to copy or move data between multiple AnalyticDB for PostgreSQL instances. A single copy of data is stored in distributed storage and can be shared by multiple instances within the specified range, requiring less storage space.
-
Ease of use is enhanced because once a share is created on a producer instance and data is imported after authorization, the shared data can be accessed on a consumer instance just as on the producer instance without needing to migrate the table schema. Shared objects and authorization changes are automatically synchronized to the consumer instance.
-
Data consistency is maintained as consumer instances can access the shared data with capabilities similar to those of producer instances. Additionally, consumer instances can read the latest data written by producer instances, ensuring the atomicity, consistency, isolation, and durability (ACID) of transactions.
Data sharing can address the following challenges:
-
Isolation between complex organizational permissions: For instance, an instance at the corporate headquarters and another at a branch can use data sharing to allow the branch instance to access specific data from the headquarters instance.
-
Isolation between complex business resources: Physical resources can be isolated between ETL and ad hoc business types, and data sharing can be used to share ETL results among instances involved in ad hoc queries.
-
Challenges in cross-business collaboration: If the same data set needs to be analyzed by R&D, sales, operations, and finance teams, data sharing allows different business groups within an organization to access the data.
Data sharing is currently in beta testing and has the following limitations:
-
Data sharing is supported for standard tables but not for partitioned tables, external tables, views, schemas, or functions.
-
Data sharing is supported for hash distributed tables but not for replicated tables or random tables.
-
Data sharing is not supported for subtransactions.
-
If multiple shares exist in a producer instance, a consumer instance can subscribe to only one of the shares at a time.
-
DDL operations are not permitted on shared tables. To perform DDL operations on a shared table, sharing must be disabled first.