This topic was translated by AI and is currently in queue for revision by our editors. Alibaba Cloud does not guarantee the accuracy of AI-translated content. Request expedited revision

Serverless mode

Updated at: 2025-03-10 06:58

AnalyticDB for PostgreSQL has introduced a Serverless mode that leverages resource pooling and mass storage capabilities of the cloud infrastructure. It combines traditional Massively Parallel Processing (MPP) database technology, online and offline integration technology, and Serverless technology to achieve compute-storage separation, second-level scaling, and real-time data sharing across multiple instances.

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

  • Europe and Americas

    US (Virginia): Virginia Zone A and Virginia Zone B

  • Middle East

    SAU (Riyadh - Partner Region): Riyadh - Partner Region 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

Migration type

Document

Supported

Data writing operations

使用INSERT ON CONFLICT覆盖写入数据

Yes

使用COPY ON CONFLICT覆盖导入数据

Yes

基于Client SDK数据写入

Yes

Table data migration

通过DataWorks导入数据

Yes

通过DTS从云数据库同步数据

Yes

通过DTS从自建数据库同步数据

Yes

通过实时计算Blink写入数据

Not supported.

You can import data by using external tables.

使用\COPY命令导入本地数据

Yes

使用OSS外表高速导入OSS数据

Yes

Hadoop生态外表联邦分析

Yes

Warehouse data migration

自建Greenplum迁移到AnalyticDB PostgreSQL版

Not supported.

You can import data by using external tables.

Teradata应用迁移至AnalyticDB PostgreSQL

Not supported.

You can import data by using external tables.

Amazon Redshift应用和数据迁移至AnalyticDB PostgreSQL

Not supported.

You can import data by using external tables.

Oracle应用迁移至云原生数据仓库 AnalyticDB PostgreSQL 版

Not supported.

You can import data by using external tables.

从自建Oracle迁移至云原生数据仓库AnalyticDB PostgreSQL

Not supported.

You can import data by using external tables.

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:

  • Up to 60 seconds are required to scale an instance with 16 or fewer nodes.

  • An instance with 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. 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.

References

  • On this page (1)
  • Introduction
  • Precautions
  • Comparison of service modes
  • Features and constraints
  • Data migration
  • Automatic scheduling (in invitational preview)
  • Elastic scaling
  • Data sharing (beta)
  • References
Feedback