TimescaleDB 2.29.2 extends PostgreSQL instead of replacing it
TimescaleDB 2.29.2 is a PostgreSQL extension for time-series and event workloads. Applications still connect with PostgreSQL clients and write SQL, while hypertables divide time-ordered data into chunks. The extension adds time buckets, retention policies, columnar storage, compression, and continuous aggregates. That combination suits teams that already depend on relational joins and transactions but have a few tables growing much faster than the rest because every device reading, trade, or application event becomes another row.
The choice avoids a second query language and a separate identity system, but it does not avoid database engineering. Our checkout contained 3,038 files, about 190,730 lines of source, and occupied 47.7 MB. This is C code tied closely to PostgreSQL internals, backed by 46 CI workflow files and a tests directory. There is no Dockerfile in this repository even though published container images are the easiest trial path described in the README.
Hypertables keep SQL while changing storage and maintenance
The README's quick start uses PostgreSQL 18 and turns a normal table into a hypertable through table options. Time-based chunks let queries skip unrelated ranges, while columnar conversion reorganizes older chunks for analytical reads. Continuous aggregates incrementally refresh changed ranges instead of rebuilding a complete materialized view. These are practical features for telemetry, financial records, event streams, and SaaS history where new data arrives continuously and most analysis groups records by time.
Those features add policies and states that an operator must understand. The sample refreshes a continuous aggregate every 1 hour, leaving the newest hour outside the materialized window. Compression or columnar conversion changes how chunks are stored and which operations are appropriate. Retention can delete old chunks on schedule. Ordinary SQL remains visible at the application boundary, yet a database administrator still needs to choose chunk intervals, observe background jobs, test late-arriving data, and understand how each extension update changes query planning.
What happened when we ran it
Our sandbox cloned commit a194697 with 3 CPUs, 8 GB of RAM, no secrets, and the lab-cpp:1 image. The source setup exited with code 1 after 12 seconds. Its last lines showed CMake using REQUIRE_ALL_TESTS=ON, then reporting that it was unable to find pg_config. CMake repeated that message and ended with configuration incomplete. The log did not reach compilation, installation of the extension, or tests.
That is a prerequisite failure, not evidence about query correctness or database speed. The CMake file searches for pg_config and stops with a fatal error when it is absent. TimescaleDB's source-build guide requires a PostgreSQL installation with development headers, a C compiler, and CMake 3.15 or newer. When several PostgreSQL versions are installed, the guide lets the builder pass the exact pg_config path to bootstrap. Our fresh image did not supply it.
A release image is simpler than the 12-second source failure
For evaluation, the README offers a local script and a Docker command using port 6543 so it does not collide with PostgreSQL on 5432. It recommends 8 GB of RAM and a PostgreSQL client. The local script tunes settings and creates persistent storage, but the page warns that this route is only for development and testing. Production installation is a separate decision covering packages or containers, storage, backups, availability, monitoring, and extension upgrades.
Source users should choose a release tag rather than main, according to the build guide. They also have to match the extension with a PostgreSQL version and install the built artifacts into that server. This coupling is part of the appeal because SQL clients, drivers, and relational features stay available. It is also the main cost: upgrading the host database and upgrading TimescaleDB become related changes that deserve staging and rollback plans.
Apache 2.0 covers one part, while tsl has service restrictions
The repository's license file says code outside tsl is generally Apache 2.0 or compatible, while code inside tsl generally uses the Timescale License. The resulting build creates separate shared objects for those parts. The Timescale License permits internal use and certain products, but restricts offering its licensed software as a database service. Any company redistributing TimescaleDB or exposing its database functions to customers should have counsel map the intended service against those terms.
An Apache-only CMake option exists, which matters for organizations that reject source-available components. It may also remove features a team expected after reading the main quick start. Our 47.7 MB checkout included both license areas, so 'available on GitHub' is not a sufficient license summary. Decide which feature set will run first, then review the license attached to those files and binaries. The GitHub API's NOASSERTION result accurately reflects that the repository does not have one simple SPDX identity.
August 2026 releases are active, with 392 issues and PRs open
GitHub showed 23,470 stars and 392 combined open issues and pull requests. The last push was September 6, 2026. Release 2.29.2 arrived on August 18, after 2.29.1 on August 4 and 2.29.0 on July 28. That release cadence and current issue discussion show active engineering. The combined open count includes pull requests, so it is not a count of unresolved defects.
Recent reports still justify version-specific testing. Issue 10477 describes an extension upgrade failing from 2.28.3 to 2.29.x in a replicated PostgreSQL 18.6 setup. Issue 10489 reports a chunk-wise aggregation planner regression affecting 2.28.0 through 2.29.2. The latest release notes also contain correctness fixes for gap filling, dimensional constraints, SkipScan, and sparse-index predicates. Mature database software can still produce wrong plans or upgrade trouble at particular version boundaries.
The 12-second failure says to test the whole PostgreSQL pairing
TimescaleDB deserves a trial when time-based data strains ordinary PostgreSQL and a separate analytical database would complicate the application. Evaluate a tagged build against the production PostgreSQL version, extensions, data distribution, and upgrade path. Stay with PostgreSQL for basic partitioning, and resolve the Timescale License before building a database service around tsl features.