TimescaleDB 2.32.0 Released: Adaptive Integer Compression by Default, Security Fixes, and More
TimescaleDB 2.32.0 shipped today (Nov 12, 2026) with Adaptive Integer Compression enabled by default, major security hardening, faster continuous aggregates, and critical concurrency fixes.
Today, November 12, 2026, the Timescale team shipped TimescaleDB 2.32.0. For Industrial IoT (IIoT) and operational technology teams running TimescaleDB as a process historian or telemetry backend, this is an especially notable release: it combines a major compression milestone with a substantial set of security hardening and data-integrity fixes.
Here is a breakdown of what landed in 2.32.0 and why it matters in production.
1. Adaptive Integer Compression (AIC) Is Now On by Default
Previewed in 2.31.0, Adaptive Integer Compression (AIC) is now enabled by default in 2.32.0, replacing DeltaDelta as the default compressor for integer columns.
In industrial and IIoT schemas, tables rarely hold only smooth floating-point sensor readings—they are packed with integer status codes, device IDs, fault flags, counters, and discrete PLC registers. Traditional DeltaDelta compression struggles with those non-monotonic integer patterns and cannot vectorize decompression efficiently.
AIC evaluates each block of up to 256 integer values and selects the fastest-decompressing encoding (such as Frame of Reference, Patched FOR, Dictionary, or RLE). In Timescale's benchmarks, this yields:
- ~50% better compression on integer columns (~10% overall database size reduction depending on schema).
- ~50% faster typical analytical queries and 5–7x faster integer decompression.
Existing compressed chunks remain readable as-is; newly compressed chunks automatically use AIC, and older chunks can be recompressed if you want the space and read-speed gains retroactively.
2. Security Hardening & Least-Privilege Background Workers
The 2.32.0 release notes emphasize that this version includes a larger set of security fixes than usual stemming from proactive security reviews, with a recommendation to upgrade promptly:
- No More Superuser for Background Worker Scheduling (#10983, #10953): The background worker scheduler now runs as the database owner rather than superuser, and database owners can start, stop, and restart background workers without superuser privileges.
- Tighter Ownership & Permission Checks (#10966, #10993, #10919): Chunk operations now require ownership of the chunk (not just the hypertable), continuous aggregate creation checks schema
CREATEprivileges, and database commands verify ownership before stopping workers. - Safer Telemetry & Policy Execution (#10965, #10962): Telemetry SSL connections now verify server certificates, and columnstore policies reset
search_pathafter everyCOMMIT.
Operational Note: Because 2.32.0 includes loader changes, a PostgreSQL server restart is required for the upgrade to take full effect.
3. Faster Continuous Aggregates & Critical Bugfixes
For teams relying on continuous aggregates for OEE rollups, shift summaries, or Grafana dashboards, 2.32.0 delivers both speed and correctness fixes:
- Faster Continuous Aggregate Refreshes (#10864): Watermark updates now happen once per batch rather than repeatedly, reducing overhead on large refresh windows.
- Variable-Bucket & Realtime Fixes (#10296, #10745, #10970): Fixes continuous aggregate refreshes skipping the last invalidated bucket on variable-sized (e.g., timezone-aware or monthly) buckets, and fixes
ORDER BYpushdown on realtime continuous aggregates. - Concurrent
UPDATE / DELETEFix (#10902): Resolves a regression introduced in 2.28.1 where concurrentUPDATEorDELETEstatements on a hypertable underREAD COMMITTEDcould silently affect0rows after waiting on a row lock. COPY FROMError Handling (#10854, #10855): Bulk ingestion viaCOPY FROMnow properly honorsON_ERROR ignoreand enforcesREJECT_LIMITon PostgreSQL 18+.- Compression Stability (#10887, #10961): Fixes a
repallocerror on certain batches over 992 rows and resolves race conditions betweencompress_chunk,decompress_chunk, and concurrent DDL.
Should You Upgrade?
Yes—especially if you are running TimescaleDB in production or managing multi-tenant/regulated industrial historians. Between the security hardening, the READ COMMITTED concurrent DML fix, and Adaptive Integer Compression enabled out of the box, TimescaleDB 2.32.0 is a worthwhile upgrade. Just remember to schedule a brief maintenance window for the required PostgreSQL restart and verify your backup before running ALTER EXTENSION timescaledb UPDATE.
Image Credits & Open Source Licensing:
- Featured Header: Grafana time-series monitoring dashboard. Screenshot: Linux Screenshots (CC BY 2.0).
- Server Infrastructure: Server racks and cabling at the KTH Parallel Computer Center. Photo: Royal Institute of Technology (CC BY-SA 3.0).