Serverless mode

Overview

Built on a cloud-native architecture, the serverless mode of AnalyticDB for PostgreSQL completely decouples compute from storage. This eliminates the need to scale both resources in fixed proportions. You can elastically and independently scale compute resources to handle business peaks and troughs, while storage remains on a continuous pay-as-you-go basis. This allows you to respond quickly to business changes and optimize costs, improving overall efficiency.

Compared to elastic storage mode, serverless mode offers the following advantages:

• Significantly reduces storage costs through on-demand usage. You no longer need to migrate historical data to other storage media. This simplifies data analysis, making it more efficient and cost-effective, and offers a comprehensive solution for the growing analytical needs of industries such as finance and the internet.

• Optimized for high-throughput write scenarios and high-performance batch processing. Its elastic scaling capabilities are ideal for businesses with large data volumes and typical peak-trough access patterns.

• The data sharing feature, built on the separation of compute and storage, removes physical machine boundaries and enables data to flow freely in the cloud. The "write once, read many" model eliminates the data silos common in traditional data warehouses, where data must be imported before access. This simplifies operations, increases efficiency, and lowers costs.

Usage notes

Feature comparison

Serverless mode is compatible with most features of elastic storage mode. The following table compares the features of the two modes.

Limitations

Serverless mode has the following limitations. In most cases, you can use the same syntax. Tools such as JDBC, ODBC, and psql work the same way in serverless mode as in elastic storage mode.

Data migration

You can migrate your existing data to serverless mode. To migrate data from an AnalyticDB for PostgreSQL instance in elastic storage mode or reserved storage mode to an instance in serverless mode, see Migrate data between AnalyticDB for PostgreSQL instances.

The following table describes the support for other data migration methods.

Autoscaling (invitational preview)

Instances in serverless mode with autoscaling enabled can automatically start and stop based on traffic. If an instance has no traffic, it automatically enters an idle state. You are not charged for compute resources when the instance is idle.

In serverless mode with autoscaling, you can manually modify the Computing Resource Threshold and Wait Time for Idle Resource Release. For more information, see Configure instance resources.

Instances in autoscaling mode are billed based on the AnalyticDB Compute Unit (ACU), which is the computing power unit of an instance. Alibaba Cloud collects the number of ACUs used each hour. Usage is billed per second, and bills are generated hourly. For more information, see Pricing.

Elastic scaling

Serverless mode supports online elastic scaling that completes within minutes. The following performance data is from lab tests:

• Scaling operations for instances with 16 or fewer compute nodes complete in under 60 seconds.

• Scaling operations for instances with more than 16 compute nodes complete in under 5 minutes.

You can use the minute-level elastic scaling of serverless mode to temporarily scale out compute nodes before an expected traffic peak, such as a major sales event, and then scale them in after the peak. AnalyticDB for PostgreSQL bills you hourly based on actual resource usage and specifications. This approach helps you balance performance and cost.

In serverless mode, each compute node has a maximum storage capacity. Before you perform a scale-in operation, you must ensure that the total data volume does not exceed the combined maximum storage capacity of the remaining nodes. For example, if your compute node specification is 2-core 8 GB memory with a maximum storage capacity of 960 GB per node, and you scale in to 4 compute nodes, your total data volume cannot exceed 3,840 GB (960 GB × 4).

The following table lists the maximum storage capacity for different compute node specifications in serverless mode.

A scaling operation causes brief service interruptions only at the start and end of the process. At all other times, your workloads remain readable and writable, ensuring continuous system availability.

Data sharing (Beta)

Compared with the traditional data warehouse method of importing and exporting data, data sharing in serverless mode provides the following advantages:

• Cost-effective storage: You do not need to copy or move data between AnalyticDB for PostgreSQL instances. Only a single copy of data is stored in the distributed storage layer, which can be accessed by multiple instances within a defined scope. This reduces storage consumption.

• Ease of use: You can access data on a consumer instance by simply creating a share, granting permissions, and importing the share. You do not need to handle table schema migrations and can access shared data just like local data. Changes, such as adding or removing shared objects and modifying permissions, are automatically synchronized to consumer instances.

• Data consistency: The performance of accessing shared data on a consumer instance is nearly identical to accessing it on the producer instance. Consumer instances can read the latest committed data from the producer, ensuring transaction ACID properties.

Data sharing helps you solve the following problems:

• Complex organizational permission isolation: For example, if a company's headquarters and a branch office each have an instance, the branch instance can be granted access to specific data in the headquarters' instance.

• Complex business resource isolation: For example, you can use separate instances to isolate resources for ETL and ad hoc query workloads. The ETL results can then be shared with the ad hoc query instance.

• Cross-business collaboration: For example, when data analysts, sales, operations, and finance teams need to analyze the same dataset, the data can be shared to allow access by different business groups within the organization.

Data sharing is currently in beta and has the following limitations:

• Data sharing is supported only for standard tables. It is not supported for partitioned tables, external tables, views, schemas, or functions.

• Data sharing is supported only for hash-distributed tables. It is not supported for replicated or randomly distributed tables.

• Data sharing does not support subtransactions.

• If a source instance has multiple shares, a destination database can subscribe to only one of them.

• To perform a DDL operation on a shared table, you must first unshare it.

References

• [Notice] Serverless mode is available for AnalyticDB for PostgreSQL

• Quick start

• Migrate data between AnalyticDB for PostgreSQL instances

• Performance test for data import and query in Serverless Pro mode

• Data sharing