TimescaleDB reliability engineering for production teams.
JusDB provides TimescaleDB reliability engineering for scoped projects, ongoing remote DBA coverage, and production support. Our engineers size chunks, set columnstore and retention policies, keep continuous aggregates current, and plan upgrades on Tiger Cloud, your own servers, and Kubernetes. 24x7 on-call is available under your service agreement.
Or request a free audit of one database instance. Already in an incident? See how incidents are handled.
- NDA before access
- Read-only by default
- Changes measured against your baseline
TimescaleDB version status
Pick the version you run
TimescaleDB 2.31
Newest releaseReleased on 20 October 2026 for PostgreSQL 16, 17, and 18.
On your own servers, each database upgrades in place with ALTER EXTENSION timescaledb UPDATE, after a backup you have test-restored.
Keep TimescaleDB updates on scheduleTimescaleDB 2.28
Last for PostgreSQL 15The last minor version for PostgreSQL 15, which TimescaleDB 2.29.0 dropped on 28 July 2026.
To move from PostgreSQL 15 to 18, upgrade TimescaleDB to 2.28 first, then PostgreSQL, then TimescaleDB again.
Plan the move off PostgreSQL 15TimescaleDB 2.19
Last for PostgreSQL 14The last release line for PostgreSQL 14, which TimescaleDB 2.20.0 dropped on 15 May 2025.
PostgreSQL 14 reaches end of life on 12 November 2026. Upgrade TimescaleDB to 2.19 first, then PostgreSQL to 15, 16, or 17, then TimescaleDB again.
Plan the move off PostgreSQL 14TimescaleDB 2.13 and multi-node
Multi-node removedThe last release with multi-node, which TimescaleDB 2.14.0 removed on 8 February 2024.
Multi-node in 2.13 runs on PostgreSQL 13 to 15, so its data moves to single-node hypertables before any upgrade past 2.13 or PostgreSQL 15.
Keep 2.13 running while you migrateVersion status from the TimescaleDB release notes, Tiger Data's supported platforms page, and the PostgreSQL versioning policy, checked 28 October 2026.
- Platforms
- Tiger Cloud, your own servers, Kubernetes, and Azure Database for PostgreSQL (Apache 2 Edition only)
- High availability
- Patroni with streaming replication, pgBackRest backups, and HA replicas on Tiger Cloud
- Incidents
- Initial-response targets are set in your service agreement. See the targets
Symptoms
Eight TimescaleDB problems we are asked to fix
Each one has a cause we can measure. The scoping call starts from your symptom, versions, and platform.
Inserts slow down as the newest chunk grows because its indexes outgrow memory, so PostgreSQL keeps flushing index pages to disk and reading them back.
Query planning takes longer every month because a short chunk_time_interval left thousands of small chunks, and set_chunk_time_interval changes only chunks created afterwards.
Background jobs fail with "out of shared memory" because each job locks every chunk it touches, and the lock table that max_locks_per_transaction sizes fills up.
A backfill into older chunks stalls or fails because it waits on the same chunk locks as the columnstore conversion running beside it.
A continuous aggregate loses history after a retention change because refreshing over raw chunks that retention dropped deletes the matching aggregate rows too.
Dashboards miss the newest data because since 2.13, continuous aggregates are materialized-only by default, so recent rows wait for the next refresh.
Compression and continuous aggregates are missing on Azure Database for PostgreSQL because it offers only the Apache 2 Edition, which leaves out the columnstore, continuous aggregates, and policies.
A pg_dump restore fails or comes back incomplete because it ran pg_restore with -j, skipped timescaledb_pre_restore, or dumped hypertables one table at a time.
If one of these is costing your team time, a scoping call is the place to start.
Book a 30-min scoping call (opens Google Calendar in a new tab)Background jobs
How a stalled background job fills a TimescaleDB disk
TimescaleDB runs columnstore, retention, and continuous aggregate policies as background jobs. When a job fails or cannot start, your application sees no error, while chunks that should be converted or dropped keep using disk.
One hypertable, three policies, three outcomes
Choose a state to see what happens to the disk.
What your team sees
Disk use stays flat as chunks arrive, and dashboards read rollups current to the last refresh.
Columnstore policy
Converts chunks once they stop receiving most writes
On schedule
Retention policy
Drops whole chunks past the retention window
On schedule
Aggregate refresh
Materializes its refresh window on every run
Current
Each policy is a background job. TimescaleDB starts it from the pool that timescaledb.max_background_workers sets, and the job_stats view counts every run and failure.
What your team sees
Disk use climbs every day and dashboards go stale, while the application itself reports no errors.
Columnstore policy
Fails or stalls while a backfill holds locks on the same chunks
Failing
Retention policy
Never starts: the log says "failed to start a background worker"
Not running
Aggregate refresh
Last successful run several days ago
Stale
New chunks stay uncompressed and expired chunks are never dropped, so storage grows until the disk fills and writes fail.
What your team sees
An alert fired on the first failed run, long before the disk was at risk.
Columnstore policy
Paused for the backfill with alter_job, then resumed
Catching up
Retention policy
Worker pool sized for every database and job
On schedule
Aggregate refresh
Refresh window kept newer than the retention cutoff
Current
The columnstore policy runs single-threaded, so a large backlog takes time to clear. Parallel convert_to_columnstore sessions clear it faster.
We size timescaledb.max_background_workers for your databases plus the jobs that run at once, and max_worker_processes to cover it and max_parallel_workers. Backfills run with the columnstore policy paused (alter_job), so the two do not compete for chunk locks.
We alert on failed runs in the job_stats and job_errors views, on a stale last_successful_finish, and on the oldest chunk still waiting for conversion. We time large backfills on a restored copy first, so the runbook says how long the backlog takes to clear.
What we cover
Full-spectrum TimescaleDB engineering
From a slow dashboard to a filling disk: EXPLAIN ANALYZE, pg_stat_statements, and the timescaledb_information views drive every change, measured against your baseline.
Hypertable optimization
Chunk sizes, keys, and indexes designed around your ingest rate, memory, and queries.
- chunk_time_interval sized so the chunks being written keep their indexes in memory
- Unique keys that include the time column, as hypertables require
- Table-swap rebuilds for hypertables already split into too many chunks
Continuous aggregates
Rollups that stay current, with refresh windows that fit your retention and late data.
- Refresh policies with start_offset and end_offset set per aggregate
- Real-time aggregation (materialized_only = false) where dashboards need the newest rows
- Hierarchical aggregates, and a separate refresh policy for backfilled ranges
Compression and storage
Hypercore's columnstore set up per hypertable, with retention that matches how long you keep data.
- segmentby and orderby chosen from the columns your queries filter and sort on
- Columnstore and retention policies timed to how your data ages
- Tiered object storage for rarely queried history, on Tiger Cloud plans that include it
Scaling and performance
We read the plans of your slowest queries first, and measure each change against your baseline.
- pg_stat_statements and EXPLAIN ANALYZE, including chunk exclusion
- Planning time and lock use tracked as chunk counts grow
- Read replicas and PgBouncer for dashboard and reporting traffic
High availability setup
Failover designed around the data loss and downtime you can accept (RPO and RTO), then drilled.
- Patroni with streaming replication on your own servers
- pgBackRest backups, with point-in-time restores tested
- Synchronous or asynchronous HA replicas chosen per workload on Tiger Cloud
SRE support
Jobs, disk growth, upgrades, and incidents, with an escalation path agreed in writing.
- Alerts on failed and late jobs in the job_stats view
- ALTER EXTENSION timescaledb UPDATE rehearsed on a copy first
- PostgreSQL upgrades planned along TimescaleDB's support matrix
Incident support
A critical (P1) page, answered within your agreement's target
JusDB keeps your recovery procedures (runbooks) written down, so an incident starts from a known plan instead of a blank page.
Initial-response targets
2 to 4 hours
Business hours
During covered business hours
30 minutes
24x7 on-call
P1 incidents
Our engineering team is in India; business-hours coverage is Mon–Fri 09:00–18:00 IST (UTC+5:30), and 24x7 on-call is available under your service agreement.
Initial-response targets, not resolution guarantees. The target for your engagement is set in your service agreement.
What happens on a P1 page
Page
You page the on-call engineer
Through the escalation path your service agreement names.
Triage
Root cause from job history and query plans
Failed jobs, chunk counts, lock waits, and slow queries traced through the timescaledb_information views, pg_stat_activity, and EXPLAIN ANALYZE.
Mitigate
Stabilize first, from the runbook
Pause the conflicting policy, cancel the blocking query, or drop chunks past your agreed retention to free disk, then fix the cause once production is steady.
After
A review after every P1
What happened, why, and the change that stops it happening again.
Before and between incidents
- Your setup, written down firstDuring onboarding we record your versions, edition, hypertables, policies, replication, and backups, so an incident starts with context.
- One escalation path, in writingYour service agreement names how to reach the on-call engineer, in which hours, and who approves a failover.
- Reviews between incidentsWe review chunk counts, failed jobs, columnstore progress, disk growth, and restore tests, and report open risks with next steps.
- Version dates trackedWe track which PostgreSQL versions each TimescaleDB release supports, and plan upgrades before your version is dropped or reaches end of life.
Process
How a TimescaleDB engagement runs, step by step
Written findings come before any change. Your team approves production changes, except routine actions you have pre-approved.
Scoping call
Your databases, TimescaleDB and PostgreSQL versions, edition, platform, and what you need covered.
Read-only review under NDA
Our engineers use named accounts with only the permissions the review needs, such as pg_monitor, then read your configuration, the timescaledb_information views, job history, and pg_stat_statements.
A written report before any change
Each finding comes with the change we propose, how we will measure it, and a way to undo it (a rollback plan).
Changes, then handover
We rehearse risky changes on a copy, apply them in the windows you approve, measure them against the baseline, and hand over updated operating instructions (runbooks).
Step one is a 30-minute scoping call.
Book a 30-min scoping call (opens Google Calendar in a new tab)Ways to work
Choose the TimescaleDB service your team needs
Start with the responsibility you need covered. Each engagement has its own scope, deliverables, access requirements, and acceptance criteria.
Projects
Scoped TimescaleDB projects
A defined piece of work with written findings, hands-on changes, and validation against your baseline.
- PostgreSQL consultingHypertable design, architecture decisions, and recovery plans, scoped as one project.
- Performance tuningSlow queries, chunk sizes, and memory settings, measured before and after.
- Migration and upgradesMoves from InfluxDB or plain PostgreSQL tables, and version upgrades, with a rollback plan.
- High availabilityPatroni design, failover drills, and tested point-in-time restores.
Ongoing
Ongoing coverage and support
JusDB monitors the databases, carries out the agreed maintenance, and responds to incidents during the coverage the proposal names. The team keeps a change record, recovery procedures, and a review after every P1.
- PostgreSQL remote DBAMonitoring, maintenance, job and backup checks, and capacity planning for TimescaleDB under an agreed scope.
- PostgreSQL supportIncident help and advice, with coverage and escalation agreed before work starts.
- Managed DBA servicesOngoing coverage for your other database engines too.
Where your TimescaleDB runs, and the tools around it
Your team and ours
What a managed TimescaleDB service still leaves to your team
Managed cloud databases automate much of the infrastructure layer, but your team still owns query performance, capacity, cost, and incident decisions.
| Question | Managed cloud service | Your own servers or Kubernetes |
|---|---|---|
| Servers, storage, and minor patches | The provider runs them. Tiger Cloud applies new TimescaleDB minor versions in a maintenance window you define. | Your team, or JusDB under your agreement. |
| Which TimescaleDB features you get | Tiger Cloud runs every Community Edition feature, plus tiered storage on the plans that include it. Azure Database for PostgreSQL offers the Apache 2 Edition only, and Amazon RDS and Google Cloud SQL do not offer TimescaleDB. | The Community Edition, free to run on your own infrastructure under the Tiger Data License (TSL). |
| Backups and restores | Automated backups and point-in-time recovery are built in. Testing a restore is still your team's job. | Your team runs pgBackRest, or pg_dump with timescaledb_pre_restore and timescaledb_post_restore around each restore. |
| Chunk sizes, policies, and queries | Yours. The provider runs the platform, not your hypertables, policies, or queries. | Yours, plus the worker and lock settings that the policies depend on. |
| Versions and upgrades | The provider's version list and calendar. Azure Database for PostgreSQL lists TimescaleDB 2.24.0 for PostgreSQL 15 to 18. | Your calendar: ALTER EXTENSION timescaledb UPDATE per database, and PostgreSQL upgrades along the support matrix. |
| Moving off later | A logical dump with pg_dump, restored into the same TimescaleDB major version. | Physical backups and streaming replication move whole clusters between servers. |
Your team keeps control
- Set business priorities, application requirements, and release plans
- Approve production changes, except routine actions you have pre-approved
- Own your cloud accounts, access policies, and vendor relationships
- Decide when maintenance can happen and how quickly service must recover
- Move the work in-house or to another provider after your agreement's notice period, with your data returned or deleted and the transition help your agreement sets out (Terms, section 8)
JusDB handles the agreed database work
- Monitor database health, investigate alerts, and involve the right people
- Review query performance, replication, capacity, and backup health
- Carry out approved changes and update the operating instructions they affect
- Report completed work, open risks, and recommended next steps
Weighing Tiger Cloud against running TimescaleDB yourself? We compare both against your workload on a scoping call.
Book a 30-min scoping call (opens Google Calendar in a new tab)Further reading
A TimescaleDB comparison, an HA guide, and a configuration tool
TimescaleDB against InfluxDB, a Patroni guide for the PostgreSQL underneath, and a configuration tool.
Comparison
TimescaleDB vs InfluxDB
A PostgreSQL extension against a purpose-built time-series database: query languages, cardinality, storage, and when each fits.
Guide
From one PostgreSQL server to a Patroni cluster
etcd, patroni.yml, replication users, and switchover tests, for the PostgreSQL that TimescaleDB runs in.
Tool
PostgreSQL configuration optimizer
Enter memory, cores, workload, and storage for an explained postgresql.conf, including shared_buffers.
FAQ
Common TimescaleDB questions
What buyers ask about TimescaleDB against other time-series tools, scale, compression, platforms, and migrations.
Still have a question?
Ask it on a scoping call. No production access needed.
Book a 30-min scoping call (opens Google Calendar in a new tab)How does TimescaleDB compare to InfluxDB or Prometheus?
JusDB compares them against your queries, retention, and team. TimescaleDB is a PostgreSQL extension, so you query it with SQL and join it to relational tables. InfluxDB 3 is a separate database queried with SQL or InfluxQL. Prometheus is a monitoring and alerting toolkit queried with PromQL, and its single-node local storage keeps 15 days of data by default.
Can TimescaleDB handle billions of rows?
Yes: JusDB designs TimescaleDB hypertables for billions of rows, with chunks sized to memory, indexes for your filters, and older chunks in the columnstore. Dashboards read continuous aggregates instead of raw rows. We watch chunk counts, because every chunk a query touches adds planning work and takes a lock.
How much can compression reduce storage costs?
JusDB measures it on a copy of your data, because the ratio depends on how rows are segmented and ordered in the columnstore. Tiger Data's documentation cites storage savings of up to 98% from columnstore compression. Retention policies, and tiering to object storage on Tiger Cloud plans that include it, lower storage costs further. On Azure Database for PostgreSQL, the Apache 2 Edition has no columnstore at all.
Do you support TimescaleDB Cloud and self-hosted?
Yes: JusDB supports TimescaleDB on Tiger Cloud, Tiger Data's managed service formerly called Timescale Cloud, and self-hosted TimescaleDB on your own servers, VMs, or Kubernetes. We also work on Azure Database for PostgreSQL, which offers the Apache 2 Edition only. Amazon RDS and Google Cloud SQL do not offer the TimescaleDB extension.
How do you handle TimescaleDB migrations?
JusDB plans each TimescaleDB migration as a rehearsed cutover, with validation and a rollback plan. From plain PostgreSQL tables, we create hypertables and backfill them in batches. From InfluxDB, we map measurements, tags, and fields to tables first, and Tiger Data's Outflux tool moves data only from versions before 2.0. A pg_dump move needs the same TimescaleDB major version on both sides. JusDB does not guarantee one cutover duration.
Next step
Talk to a TimescaleDB engineer about your databases
Tell us what is slow, fragile, or due to change. The first 30-minute call covers your databases, current ownership, and required coverage. No production access is needed. Or request a free audit of one database instance, subject to availability: mutual NDA before read-only access, a prioritized report within one week after access is ready, and no obligation.
NDA before access, read-only by default, and written scope first
Compare with other databases
If you are weighing alternatives, these are the databases most often compared with this one.
PostgreSQL
TimescaleDB runs as a PostgreSQL extension, so the PostgreSQL hub covers the base it depends on: replication, upgrades, and tuning.
InfluxDB
A purpose-built time-series database and the usual comparison for metrics and sensor data. Compare query languages, retention, and storage.
ClickHouse
A columnar database compared with TimescaleDB for analytics over very large event tables.
pgvector
Another PostgreSQL extension, for vector similarity search in the same database as your time-series data.