September moved the database portfolio in two directions at once. Five services became available in Brazil (São Paulo), putting relational, caching, and analytical workloads closer to Latin American users. On the platform side, PolarDB added automated cold-data archiving and immutable backups, while ApsaraDB RDS for PostgreSQL brought vector index quantization and DuckDB-based slow-SQL analysis to its kernel. Below is the full list of 13 updates across eight database services, followed by four highlights and the remaining releases at a glance.
| Product | Feature | Type |
|---|---|---|
| PolarDB for MySQL · ApsaraDB RDS for MySQL · ApsaraDB RDS for PostgreSQL · Tair · ApsaraDB for ClickHouse | Brazil (São Paulo) Region | Region Expansion |
| PolarDB for MySQL | TTL-Based Automatic Data Archiving | New Feature |
| PolarDB for MySQL | Cold Data Archiving in IBD Format | New Feature |
| PolarDB for MySQL | Serverless Cross-Machine Scaling | Enhancement |
| PolarDB for PostgreSQL | Immutable Backup | New Feature |
| PolarDB for PostgreSQL (Compatible with Oracle) | Immutable Backup | New Feature |
| ApsaraDB RDS for PostgreSQL | AliPG 20260915 Minor Kernel Version | New Version |
| ApsaraDB for MongoDB | Advanced Backup (Sparse Backup) | New Feature |
| ApsaraDB for ClickHouse | Cluster Part Metric Collection Optimization | Optimization |
What it is:
PolarDB for MySQL, ApsaraDB RDS for MySQL, ApsaraDB RDS for PostgreSQL, Tair (Redis OSS-Compatible), and ApsaraDB for ClickHouse Enterprise Edition (Serverless) are now available in Brazil (São Paulo).
Description:
Alibaba Cloud opened its first Brazil region in São Paulo in late August with two zones; September brought the database layer. Teams serving Brazilian users no longer have to route every query to US East, Europe, or Asia Pacific and absorb the round-trip cost. Transactional data can stay in-country, which simplifies data-residency planning for organizations that need local storage. The release also makes practical topologies possible: a São Paulo primary with cross-region disaster recovery, a local read path for latency-sensitive applications while analytics runs elsewhere, or a fully local stack spanning relational, caching, and analytical services. ClickHouse's Serverless form is particularly useful here, because it lets teams add bursty analytical capacity without committing to a fixed cluster size.
Why developers and enterprises should pay attention:
Note: Region availability, instance types, zone coverage, and supported features differ by service. Confirm the current specifications on the purchase page before planning a deployment.
What it is:
PolarDB for MySQL adds two complementary archiving capabilities: TTL-based automatic archiving and IBD-format archiving built on PolarStore shared storage with OSS hybrid storage.
Description:
Transactional tables accumulate rows that are rarely read but still consume primary storage, backup capacity, and memory. Traditionally, teams handled this with scheduled scripts, shadow tables, and manual verification, and every archiving job carried the risk of locking a large table or breaking an application query. TTL archiving replaces that routine with a time-based policy: rows that fall outside the defined retention window move into an archive table, and cold data is placed in low-cost OSS storage. IBD archiving takes a different route and keeps cold data in InnoDB's native format through PolarStore, so archived tables retain their InnoDB layout and index structures instead of becoming opaque dumps. Partitioned tables can be archived at partition granularity, and on the advanced edition common DDL such as adding columns or creating indexes remains available after archiving, which makes the archived data easier to keep in step with a changing schema.
Why developers and enterprises should pay attention:
Note: TTL archiving requires MySQL 8.0.2 or later, tables with explicit primary keys, and no FULLTEXT or SPATIAL indexes. IBD archiving supports regular tables in the basic edition; partitioned tables, partition-level operations, and post-archive DDL such as adding columns or creating indexes require the advanced edition.
📄 TTL archiving → · IBD-format archiving →
What it is:
ApsaraDB RDS for PostgreSQL releases minor kernel version 20260915, which adds HNSW-RaBitQ quantized vector indexes on PostgreSQL 18 and enhances the rds_duckdb extension on PostgreSQL 16–18.
Description:
Vector search has a memory problem: an HNSW index over millions of embeddings can grow larger than the instance's memory, and once the graph no longer fits, every traversal pays for disk access. On PostgreSQL 18, the pgvector extension now supports HNSW-RaBitQ quantized indexes, which compress vector representations so that a larger share of the index stays resident while preserving more recall than a simple binary-quantized index at the same search effort. The release also strengthens rds_duckdb on PostgreSQL 16–18 with one-click slow SQL analysis and automatic conversion of every table referenced in a statement into a DuckDB table, so an analytical query can run on a columnar engine without an ETL pipeline. PostgreSQL 14–18 additionally gain the amcheck, tsm_system_rows, and tsm_system_time extensions for integrity checking and sampling.
Why developers and enterprises should pay attention:
amcheck, tsm_system_rows, and tsm_system_time cover index integrity checks and sampling queries without custom extensions.Note: Feature availability depends on the PostgreSQL major version. The three new extensions target PostgreSQL 14–18, RaBitQ quantized indexes require PostgreSQL 18, and the DuckDB enhancements require PostgreSQL 16–18. Confirm the instance kernel version in the console before relying on a specific capability.
📄 Release notes → · Supported extensions →
What it is:
PolarDB for PostgreSQL and PolarDB for PostgreSQL (Compatible with Oracle) now support immutable backup, which locks backup sets as read-only for a configured retention period.
Description:
Backups are often the first target in a ransomware attack or a destructive insider action, because an attacker who can delete or encrypt backups can force a payment or prevent recovery. Immutable backup changes that equation. When enabled at the cluster level, backup sets cannot be modified or deleted by any means during the lock period, including by highly privileged accounts, and the protection covers both data and log backups. The minimum retention period is seven days. Enabling it is a one-way decision: immutable backup cannot be disabled afterwards, so the guarantee does not depend on someone remembering to keep a setting switched on. For teams that need to demonstrate that recovery data is tamper-proof, this turns an operational policy into an enforced property of the platform.
Why developers and enterprises should pay attention:
Note: Immutable backup is enabled at the cluster level and cannot be disabled after activation. The minimum retention period is seven days, and all data and log backups are covered. Review the retention commitment before enabling it on production clusters.
📄 PostgreSQL documentation → · Oracle-compatible documentation →
Serverless clusters can now scale beyond the machine they currently run on. When local resources are exhausted and vertical scaling can no longer proceed, the cross-machine mechanism migrates the cluster to a machine with more available capacity. The migration takes roughly 5 to 10 minutes, and the primary node may be unavailable for 30 to 90 seconds; billing continues by the second during the move. For workloads whose growth is no longer bounded by a single machine, this removes a hard ceiling, provided the application can tolerate a short, planned interruption.
ApsaraDB for MongoDB adds advanced backup (sparse backup) alongside standard backup. Sparse backup keeps recent recovery points dense and retains older ones at a lower frequency, which reduces the cost of long retention without abandoning older restore points. It requires cloud-disk instances, and once a cluster switches to the advanced mode it cannot switch back, so the retention profile should be chosen with the recovery-point objectives in mind.
ApsaraDB for ClickHouse Enterprise Edition has narrowed the scope of Part-related monitoring metrics such as Data Parts and Inactive Data Parts to user tables only, excluding system tables in the system database. The change reduces the volume of metric data collected and improves monitoring performance on clusters with many internal parts, without changing how user-table health is reported.
September's releases reflect two forces shaping database platforms: reach and control. The Brazil region shortens the distance between services and users, while automated archiving, immutable backups, and sparse backups put data lifecycle and protection under platform enforcement rather than individual discipline. The RDS for PostgreSQL kernel update points in a third direction, making AI-oriented indexing and columnar analytics available inside an operational database. Follow the next monthly roundup for more updates across the Alibaba Cloud database portfolio.
Learn more about Alibaba Cloud Database services: ApsaraDB Product Page
[Infographic] Highlights | Database New Features in August 2026
CloudSecurity - October 15, 2026
ApsaraDB - May 21, 2026
ApsaraDB - March 29, 2026
ApsaraDB - April 20, 2026
ApsaraDB - September 23, 2026
ApsaraDB - February 27, 2026
ApsaraDB for ClickHouse
ApsaraDB for ClickHouse is a distributed column-oriented database service that provides real-time analysis.
Learn More
ApsaraDB for OceanBase
A financial-grade distributed relational database that features high stability, high scalability, and high performance.
Learn More
ApsaraDB for Cassandra
A database engine fully compatible with Apache Cassandra with enterprise-level SLA assurance.
Learn More
PolarDB for PostgreSQL
Alibaba Cloud PolarDB for PostgreSQL is an in-house relational database service 100% compatible with PostgreSQL and highly compatible with the Oracle syntax.
Learn MoreMore Posts by ApsaraDB
