ApsaraDB RDS:ApsaraDB RDS for PostgreSQL supports PostgreSQL 17

Performance

VACUUM improvements

PostgreSQL 17 introduces TIDStore, a radix tree data structure that tracks dead tuples more efficiently and with lower memory overhead. The 1 GB memory cap on VACUUM is also removed: when deleting tables with indexes, VACUUM now holds more dead tuples in memory before triggering an index scan, reducing the number of index scans, speeding up the VACUUM process, and saving disk I/O.

Write-ahead log (WAL)

WAL lock management is optimized to improve throughput under highly concurrent write workloads.

Query optimizer

• Statistics and WITH clauses can be used together for deeper query optimization.

• B-tree indexes are now used for IN clause lookups, significantly improving query speed.

• Redundant IS NOT NULL constraints are automatically removed for columns that already have NOT NULL constraints.

Logical replication

• Logical replication slot failover is now supported.

• Logical replication slots are preserved when you upgrade from PostgreSQL 17 to a later version.

• pg_createsubscriber, a new binary tool, converts a physical replica into a logical replica.

• Logical decoding performance is improved for workloads involving large numbers of subtransactions.

Monitoring

• pg_stat_checkpointer, a new system view, provides checkpoint statistics to help monitor checkpoint frequency and resource usage.

• pg_wait_events, a new system view, displays the causes of wait events.

• EXPLAIN now reports the memory usage of the query optimizer.

Permissions and security

• The MAINTAIN table-level privilege is added, and the pg_maintain user is retained. This provides fine-grained control over maintenance operations such as VACUUM and REINDEX.

• The sslnegotiation connection parameter enables direct Transport Layer Security (TLS) handshakes, reducing network round-trip time (RTT).

Developer experience

JSON support

TOAST utility

pg_column_toast_chunk_id() returns the chunk ID of a specific TOAST value, useful for low-level storage inspection.

Cost optimization

(New) Data archiving for general ESSDs

Store infrequently accessed data in Object Storage Service (OSS) buckets via tablespaces and external file systems. Run Data Definition Language (DDL) statements to move data between Enterprise SSDs (ESSDs) and OSS without application changes. Storage costs are 80% lower than performance level 1 (PL1) ESSDs.

Best for: Instances with large amounts of cold data.

For more information, see Use the data archiving feature of general ESSDs.

Tablespace-level transparent page compression (TPC)

TPC compresses page data in the buffer pool in real time — data is compressed on writes and decompressed on reads, with no application changes required. On average, TPC reduces storage costs by approximately 50%, reduces disk I/O by approximately 50%, and increases transactions per second (TPS) by up to 100% in read scenarios.

Best for: Instances with large datasets and high read throughput requirements.

For more information, see Use the TPC feature.

Analytical performance

(New) rds_duckdb extension — OLAP query acceleration

The rds_duckdb extension is built on DuckDB and accelerates analytical queries directly on your RDS instance. Export on-premises tables as column-oriented tables and enable the Analytical Processing Query Acceleration (AP) feature to run complex queries significantly faster.

Best for: Complex analytical and reporting queries.

For more information, see Use the rds_duckdb extension to accelerate AP queries.

Security

Transparent Data Encryption (TDE)

All encryption and decryption happen in memory — data is plaintext in memory and ciphertext on disk, protecting against data leaks if storage media is stolen. TDE uses fine-grained encryption to minimize performance impact and requires no changes to your database usage patterns.

Best for: Workloads with data encryption requirements or security compliance obligations.

For more information, see Configure TDE.

Operations and maintenance

Cache eviction

In multi-table scenarios, PostgreSQL caches table metadata in persistent connections and never proactively releases it, which can cause out of memory (OOM) errors at scale. Cache eviction automatically manages this metadata cache to keep memory usage under control.

Best for: Software as a service (SaaS) workloads with many persistent connections and large numbers of tables.

For more information, see Use the cache eviction feature.

SQL throttling

The rds_ccl extension limits the maximum number of concurrent SQL statements to prevent database overload, protecting stability during traffic spikes.

Best for: High-concurrency access, malicious query prevention, and resource usage control.

For more information, see Use the rds_ccl extension to perform SQL throttling.

Extensions

ApsaraDB RDS for PostgreSQL supports a broad set of self-developed and third-party extensions. For the full list, see Supported extensions.

Choose an upgrade mode

ApsaraDB RDS for PostgreSQL supports two upgrade modes. For production workloads, blue-green deployment is recommended because it lets you verify compatibility before committing and switch endpoints with no service interruption.

Blue-green deployment options:

• No cutting: Runs the upgrade on a parallel instance without switching traffic. Use this to verify application compatibility before committing.

• Cutover: Switches the endpoint from the original instance to the upgraded instance automatically. No service interruption.

For more information, see Upgrade the major engine version.

Create a new instance running PostgreSQL 17

To create a new RDS instance running PostgreSQL 17 instead of upgrading, see Create an ApsaraDB RDS for PostgreSQL instance.