TimescaleDB
Term 15 of 68 in the ERPStack technical glossary
What is TimescaleDB?
TimescaleDB is an open-source time-series database extension for PostgreSQL that optimizes database performance for time-series logging, IoT telemetry, and high-frequency operational metrics.
TimescaleDB at a glance
- What it is
- 1 PostgreSQL extension, not a separate engine — ordinary SQL and existing drivers still apply
- Core structure
- Hypertables that partition automatically by time, typically into 1-week chunks
- Compression
- Columnar compression on older chunks, so 12 months of history costs far less to retain
- Best fit
- Append-heavy series: 1 row per sensor reading, meter tick or audit event
- Built with
- TimescaleDB as a PostgreSQL 18 extension, queried through Drizzle ORM 0.45 from Next.js 16, fed by Apache Kafka, provisioned with Terraform on AWS, thresholds alerted through Sentry
- Numbers that matter
- 1-week chunks by default; 12 months of history compressed rather than deleted; 0 new drivers; 1 connection shared with the rest of the schema
- Compare with
- ClickHouse for analytics, Redis for hot counters, MongoDB Atlas for documents
- Commonly paired with
- Apache Kafka ingestion, Drizzle ORM queries and Sentry alert thresholds
- Version horizon
- Upstream PostgreSQL supports majors 14 through 18, and PostgreSQL 18 reaches end of life on 14 November 2030 — the horizon any extension-based choice inherits.
How TimescaleDB works in production
The ERPStack approach to TimescaleDB
We deploy TimescaleDB instances for clients with high-frequency telemetry, such as AgTech field sensors or mining logistics tracking, keeping querying latency low.
Frequently asked questions about TimescaleDB
When do you need TimescaleDB rather than plain tables?
When rows arrive continuously and are queried by time. TimescaleDB partitions a table into time chunks automatically, so a query for last week touches 1 chunk instead of scanning years of history, and old chunks can be compressed or dropped by policy. Below a few million rows an ordinary indexed PostgreSQL table is simpler and fast enough — the extension earns its place as retention grows.
Does adopting TimescaleDB mean a new database to operate?
No, and that is the main argument for it. TimescaleDB is an extension to PostgreSQL, so it uses the same connection, the same SQL, the same drivers, the same backups and the same access control. Sensor data can be joined directly against business tables in 1 query. A dedicated time-series product would give you a second system to secure, back up and learn.
How does compression change retention economics?
It makes long history affordable. TimescaleDB converts older chunks to a columnar layout, which compresses well because consecutive readings are similar, while keeping them queryable. That turns the usual choice — delete history or pay for it at full price — into a retention policy: recent data uncompressed for fast writes, older data compressed, oldest data dropped on a schedule you set deliberately.
What does ERPStack use time-series storage for?
Operational telemetry inside business systems. TimescaleDB suits production-line sensor feeds, energy meter readings, fleet positions and high-volume audit events — anything appended constantly and read by time window. Keeping it in PostgreSQL means an alert threshold can be evaluated against the same database that holds the work order it relates to, without shipping data between 2 systems first.