Data archiving for ApsaraDB RDS for PostgreSQL - ApsaraDB RDS

As your dataset grows, cold data — rarely accessed historical records — drives up storage costs on Enterprise SSDs (ESSDs). The data archiving feature lets you move cold tables and indexes from ESSDs to Object Storage Service (OSS) buckets, reducing storage costs by 80% compared to performance level 1 (PL1) ESSDs. Archived data stays queryable on read-only instances.

Important

After you archive data to OSS, queries on archived tables are supported only on read-only instances. Plan your archiving strategy accordingly before enabling this feature.

How it works

When you enable data archiving, RDS creates two storage layers:

Layer	Tablespace	Storage	Use for
`/data` directory	`pg_default`	General ESSD	Active, frequently accessed data
`/cold-data` directory	`rds_oss`	OSS bucket	Cold, infrequently accessed data

Move data between layers using ALTER TABLE and ALTER INDEX DDL statements. Both standard tables and child partitioned tables are supported. Table data and index data are processed separately during transfer.

Workflow overview

Check prerequisites — Verify your instance meets the version, edition, and storage requirements.
Run VACUUM — Clean up target tables before archiving to prevent autovacuum overhead on OSS.
Enable data archiving — Turn on the feature from the ApsaraDB RDS buy page or the instance details page.
Archive tables and indexes — Run ALTER TABLE and ALTER INDEX to move cold data to the rds_oss tablespace.
Query archived data — Use read-only instances to query archived tables.
View archived data — Monitor archived databases on the Cold Storage Management page.

Prerequisites

Before you begin, make sure that:

The instance runs PostgreSQL 12 or later
The minor engine version is 20240530 or later (for PostgreSQL 15, 20240229 or later is sufficient; to update, see Update the minor engine version)
The instance runs RDS Basic Edition or RDS High-availability Edition
The instance uses the standard or YiTian product type
The instance uses general ESSDs as the storage type (if your instance uses ESSDs, change the storage type to general ESSD first)
The billing method is subscription or pay-as-you-go
The instance has 8 or more CPU cores
The instance does not reside in the South Korea (Seoul), UAE (Dubai), or UK (London) region

Enable data archiving

Enable data archiving when you create an instance, or on an existing instance that uses general ESSDs.

On the ApsaraDB RDS buy page (new instances)

Go to the ApsaraDB RDS buy page.
Set Storage Type to General ESSD. In the Configuration section, turn on Data Archiving.

On the instance details page (existing instances)

Log on to the ApsaraDB RDS console and go to the Instances page. In the top navigation bar, select the region of your instance. Find the instance and click its ID.
On the instance details page, click Configure General ESSD in the Basic Information section. In the Data Archiving card of the dialog box, turn on Data Archiving.

Important

Enabling data archiving causes a transient connection lasting approximately 30 seconds. Enable the feature during off-peak hours and make sure your application is configured to automatically reconnect.

Archive and retrieve data

Before archiving a table, run VACUUM to clean it up. OSS storage performance differs significantly from ESSD performance, and autovacuum efficiency on OSS tablespaces is low. Setting the all_visible and all_frozen flags on all pages before archiving prevents autovacuum from running against archived tablespaces.

Step 1: Run VACUUM on the target table

VACUUM (FREEZE) table_name;

Use the VERBOSE option to display cleanup progress and confirm a complete cleanup:

VACUUM (FREEZE, INDEX_CLEANUP on) table_name;

Additional parameters by PostgreSQL version:

PostgreSQL version	Additional parameter	Purpose
14 or later	`PROCESS_TOAST`	Cleans TOAST tables
16 or later	`PROCESS_MAIN`	Cleans the primary table

Note

If your instance has long-running transactions or replication slots, complete cleanup may not be possible because specific transaction IDs must be retained.

For full VACUUM documentation, see VACUUM.

Step 2: Move data to OSS (archive)

After VACUUM completes, move the table and its indexes to the rds_oss tablespace:

-- Archive a table
ALTER TABLE $tableName SET tablespace rds_oss;

-- Archive its index
ALTER INDEX $indexName SET tablespace rds_oss;

Step 3: Retrieve data from OSS (unarchive)

To move data back to ESSD storage:

-- Retrieve a table
ALTER TABLE $tableName SET tablespace pg_default;

-- Retrieve its index
ALTER INDEX $indexName SET tablespace pg_default;

Query archived data

Archived data is accessible only on read-only instances. Connect to your read-only instance and run queries as normal.

View archived data

Go to the Instances page. In the top navigation bar, select the region of your instance. Find the instance and click its ID.
In the left-side navigation pane, click Cold Storage Management.
In the Archive Layer Settings section, view the databases for which data archiving is enabled.

Disable data archiving

Go to the Instances page. In the top navigation bar, select the region of your instance. Find the instance and click its ID.
On the instance details page, click Configure General ESSD in the Basic Information section. In the Data Archiving card, turn off Data Archiving.

Important

Disabling data archiving causes a transient connection lasting approximately 30 seconds.
You cannot disable data archiving while the OSS bucket contains archived tables. Convert archived tables back to online tables or DROP them before disabling the feature.

Billing

Billing details

Data archiving is billed on a pay-as-you-go basis, charged by the amount of data stored in OSS.

Region	RDS Basic Edition	RDS High-availability Edition	RDS Cluster Edition (per node)
China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Shenzhen), China (Heyuan), China (Guangzhou), and China (Chengdu)	USD 0.000032/GB-hour	USD 0.000065/GB-hour	USD 0.000032/GB-hour
China (Hong Kong), Japan (Tokyo), Singapore, Indonesia (Jakarta), and Germany (Frankfurt)	USD 0.000034/GB-hour	USD 0.000068/GB-hour	USD 0.000034/GB-hour
Philippines (Manila) and US (Silicon Valley)	USD 0.000058/GB-hour	USD 0.000117/GB-hour	USD 0.000058/GB-hour
Malaysia (Kuala Lumpur)	USD 0.000057/GB-hour	USD 0.000114/GB-hour	USD 0.000057/GB-hour
US (Virginia)	USD 0.000054/GB-hour	USD 0.000108/GB-hour	USD 0.000054/GB-hour

Note

Data archiving is not available in the Thailand (Bangkok), South Korea (Seoul), UK (London), and UAE (Dubai) regions.

After archiving large amounts of data, you can reduce unused ESSD storage to further lower costs. For more information, see Reduce the storage capacity of an ApsaraDB RDS for PostgreSQL instance that uses cloud disks.

Limitations

Backup restrictions

Enabling data archiving affects the following backup features:

Single-digit second backups are not supported.
Cross-region backups are not supported.
Individual database and table restore recovers only data that has not been archived.
Downloaded backup sets contain only data that has not been archived.

Note

Backup and restoration speed decreases when data archiving is enabled, because the system must restore archived data during the process.

Performance considerations

OSS access latency reaches 10 ms, which is higher than ESSD latency. Tables cached in the RDS instance's buffer pool or the operating system's page cache may be served more quickly.
Reading data from OSS consumes memory and a portion of the Elastic Compute Service (ECS) network bandwidth. Adjust data transfer frequency and access patterns accordingly.

Data access restrictions

Archived data has the following query restriction:

Queries: Supported only on read-only instances.

References

Introduction to storage types