5 TimescaleDB Alternatives in 2026: An Honest Comparison

Most "TimescaleDB alternatives" posts start from the wrong question. They line up six time-series databases, rank them by ingestion throughput, and hand you a winner. That framing skips the only question that actually matters when you are already running TimescaleDB: do you need to leave Postgres at all?

For a lot of teams the answer is no. TimescaleDB is a good product, it is shipping real engineering, and the version you are running is probably fine. If you are here because of a specific pain, the fix might be a Postgres configuration change or a different extension rather than a migration that costs you a quarter.

This post is organized around that question. The first option is not a database at all, it is staying where you are. The five after it are for teams who have decided the Postgres executor is the actual ceiling.

I should be upfront about my bias. I worked at InfluxData. I now run Basekick Labs, where we build Arc, which is the sixth option on this list. I have a horse in this race and I will say so plainly wherever it matters. I will also tell you where Arc is the wrong choice, because a comparison that never recommends a competitor is an ad.

Why teams look past TimescaleDB

Being specific about the reasons matters, because three of the five below are solvable without migrating.

The executor ceiling. TimescaleDB ships Hypercore, a genuine hybrid row-and-columnstore engine. Hot data lands in row format, cooled chunks convert to compressed columnstore, and specific operators have vectorized execution paths. The old critique that "everything decompresses back to rows" is out of date and I am not going to repeat it. But the query planner underneath is still PostgreSQL's, and vectorization covers specific operators rather than the whole plan. On aggregation-heavy analytical scans over very large datasets, engines that are columnar end to end pull away. We measured this: on ClickBench, Arc was 4.6x faster than TimescaleDB on combined score.

Write scaling stops at one machine. Multi-node distributed hypertables were deprecated, with 2.13 the last release to include them. Roughly 1% of deployments used the feature and the maintenance cost was not worth it, which is a defensible product call. Be precise about what this does and does not mean. Reads scale fine on Tiger Cloud, which offers read replica sets behind a single endpoint, so a read-heavy dashboard workload has a managed answer. Writes are the constraint: scaling ingestion past a single node means application-level sharding that you build and operate yourself, and the read replica option is Tiger Cloud only rather than something you get self-hosted.

The license line moved, and it is where the good features are. The Apache 2.0 edition gets basic hypertable operations, time_bucket, and core hyperfunctions. Hypercore, continuous aggregates, retention policies, advanced hyperfunctions, job scheduling, and SkipScan are all under the Tiger Data License, which is source-available rather than OSI open source and prohibits offering the software as a service. Self-managed use of TSL features is free. If you assumed "open source Postgres extension" meant Apache 2.0 across the board, check which features you actually depend on.

Upgrade treadmill. TimescaleDB 2.29.0 dropped support for PostgreSQL 15, leaving 16, 17, and 18. If you are on PG15 you now have a Postgres major upgrade in front of any TimescaleDB upgrade. That is normal software lifecycle, not a scandal, but it is real work that lands on your calendar.

Strategic drift toward AI. Tiger Data, which is what Timescale renamed itself to in June 2025, has moved a lot of its narrative toward Agentic Postgres: pgai, pgvectorscale, pg_textsearch, and a copy-on-write storage layer for forking databases. It is coherent work and it may be exactly what you want. If what you wanted was a vendor with singular focus on time-series performance, the center of gravity has shifted.

One more data point worth knowing: Supabase deprecated the extension for projects on Postgres 17, keeping it on Postgres 15 until that reaches end of life. Their recommended path is native partitioning via pg_partman. If you run TimescaleDB on Supabase, this is a forced decision rather than an optional one.

To be fair, because this is the part most comparison posts leave out: TimescaleDB is not standing still. Version 2.29.1 shipped on August 4, 2026. Recent releases added vectorized filters, bloom filter optimization delivering up to 160x speedups on some UPDATE and DELETE patterns, chunk exclusion for DML, and CASE expression vectorization. If you last evaluated TimescaleDB two years ago, your mental model is stale.

What to look for in an alternative

Name the criteria before the list, and weight them for your own workload:

1. Query language. SQL, PromQL, or a custom DSL. Familiarity is worth more than benchmark points.
2. Do you need transactions? If time-series data sits alongside user accounts and orders in the same consistency boundary, most of this list is wrong for you.
3. Storage portability. Proprietary engine files, or open formats you can read with other tools.
4. Operational model. Single binary, clustered with an operator, or an extension on a database you already run.
5. License. Apache 2.0, AGPL, source-available, or proprietary. Find out what your legal team bars before the POC, not after.
6. Migration cost from hypertables. Schema mapping, query rewriting, and what happens to your continuous aggregates.

The alternatives

1. Stay on Postgres

The option worth pricing first. If your pain is a specific feature or cost line rather than a hard performance wall, you may be able to solve it without leaving.

What it's best at. You keep transactions, joins, every Postgres client library, your existing operational knowledge, and your backups. pg_partman handles time-based partitioning natively and is what Supabase now points people toward. For columnar analytics inside Postgres, pg_mooncake pushes execution to DuckDB for columnstore tables, and Citus columnar remains credible for read-mostly data you will not update. Hydra, a Citus columnar fork, is worth knowing about but check its activity before you adopt it: the latest release is v1.1.2 from April 2024.

Where it falls short. You are assembling what TimescaleDB packaged for you, and the pieces have less polish than continuous aggregates and retention policies. None of these gets you past the fundamental Postgres executor ceiling on heavy analytical aggregation. ParadeDB's pg_analytics was discontinued in March 2025, which is a reminder that this extension ecosystem consolidates. You are still on one machine.

License. PostgreSQL License for core and pg_partman. Extension licenses vary, check individually.

TimescaleDB migration path. The shortest on this list. Convert hypertables to native partitioning managed by pg_partman; Supabase publishes a guide for exactly this. time_bucket calls need replacing with date_trunc or a custom function. Continuous aggregates become materialized views plus a scheduler.

Best for. Teams whose complaint is licensing, cost, or a single missing feature, and whose data volume has not actually outgrown Postgres.

2. ClickHouse

ClickHouse is a columnar OLAP database built for analytical scans over very large datasets.

What it's best at. Raw analytical query speed at scale, with genuine horizontal scaling through sharding and replication. Compression is excellent. If your workload is aggregation over billions of rows with high query concurrency, this is the category-defining answer and the ecosystem is deep.

Where it falls short. Operationally heavier than a Postgres extension. It is not a transactional database in the sense a Postgres user means, and while it has experimental transaction support and ACID guarantees at the single-block level, if you need updates and deletes as a routine part of your workload rather than an occasional correction, you will fight the engine. The SQL dialect is close to standard but not identical, and joins are weaker than a relational database. Running a cluster properly means learning ZooKeeper or ClickHouse Keeper.

License. Apache 2.0, with ClickHouse Cloud as the commercial offering.

TimescaleDB migration path. No shared heritage. Export hypertables to CSV or Parquet and load them. Schema redesign is real work: MergeTree engine selection, ordering keys, and partition keys have no Postgres equivalent and getting them wrong costs you the performance you migrated for. Every query gets rewritten.

Best for. Large-scale analytical workloads where query performance dominates and you have the operational capacity to run a cluster.

3. InfluxDB 3

InfluxDB 3 is the Rust rewrite built on Apache Arrow, DataFusion, and Parquet. Core reached GA in April 2025.

What it's best at. Purpose-built time-series ergonomics, a very large existing community, and Telegraf, which remains the best-in-class collection agent. v3 is architecturally modern: columnar, object-storage backed, SQL-queryable. If your workload is classic metrics and telemetry, the data model fits without contortion.

Where it falls short. Three major versions with three storage engines and a query language migration from InfluxQL to Flux and back to SQL. Teams that invested in Flux feel that history. Clustering and high availability sit in the commercial tiers.

License. MIT and Apache 2.0 for Core, commercial for Enterprise and Cloud.

TimescaleDB migration path. No direct tooling. Your hypertable schema needs mapping into measurements, tags, and fields, and that mapping is lossy in both directions. Relational data alongside your time-series does not have a home here. Expect to rewrite queries entirely.

Best for. Teams whose workload is genuinely metrics-shaped and who value Telegraf and the surrounding ecosystem.

4. VictoriaMetrics

VictoriaMetrics is a Prometheus-compatible metrics database in Go.

What it's best at. Operational simplicity and compression on observability workloads. It speaks PromQL, accepts Prometheus remote-write, and works with existing Grafana dashboards and Alertmanager rules unchanged. The single-binary deployment is genuinely a single binary.

Where it falls short. This is a metrics database, and TimescaleDB usually is not being used purely for metrics. If your hypertables hold business events, sensor readings you join against a device registry, or anything you query relationally, PromQL is a poor fit and the data model will not accept your schema cleanly. Logs and traces live in separate sister products, VictoriaLogs and VictoriaTraces, with separate query interfaces.

License. Apache 2.0, with a commercial Enterprise tier.

TimescaleDB migration path. Realistically a rewrite rather than a migration. This is the option on the list with the biggest conceptual distance from a hypertable, and it only makes sense if your workload was metrics all along.

Best for. Teams whose TimescaleDB instance is really an observability metrics store, who want PromQL and Grafana.

5. Arc

Arc is a time-series database built on a columnar engine, for metrics, logs, traces, and events. I built it after leaving InfluxData. DuckDB is the query engine and storage is native Apache Parquet on S3, Azure Blob, MinIO, or local disk. It has been public since October 2025.

I am including it last because it is mine, and because for a specific kind of TimescaleDB workload I think it is the strongest option here. I will be specific about what it costs you.

What it's best at. Full analytical SQL through DuckDB, so window functions, CTEs, and complex joins all work. If your team writes Postgres SQL, most of what you know transfers, and time_bucket() works unchanged. Storage is plain Parquet in your own object storage, readable by DuckDB, Spark, Polars, ClickHouse, or BigQuery with no export step, so leaving Arc later does not require a migration project. Deployment is a single Go binary with no extension stack to manage.

On ClickBench, Arc is 4.6x faster than TimescaleDB on combined score and 6.5x on hot runs on identical c6a.4xlarge hardware. Arc on that instance also beat every Timescale Cloud tier we tested, including the 16 vCPU / 64 GB managed offering.

On ingestion, Arc sustains 19.9M records/sec against TimescaleDB's best sustained result of 1.81M rec/sec, which is roughly 11x. That is the figure we publish on our comparison and migration pages, and you should know exactly how it is built before you use it. Those two numbers come from different runs. The apples-to-apples number is 9.6x: in the head-to-head test, on one MacBook Pro, Arc did 17.3M against TimescaleDB's 1.81M. If you only take one number from this section, take 9.6x. In that test we gave TimescaleDB every advantage we could, including Community Edition with hypertables and columnar compression, pgx COPY, a tuned Postgres config, and multiple batch sizes and worker counts to find its ceiling, and it used 10,000-row batches against Arc's 1,000. Both figures are first-party, neither was third-party validated, and neither ran on server-grade hardware. Reproduce them on your own workload before trusting them, and apply the same skepticism to every vendor here including us.

Where it falls short. Arc is the youngest option here by a wide margin, public since October 2025, with a correspondingly small community of roughly 600 GitHub stars. If you need a database with a decade of public production deployments behind it, that is a real argument for TimescaleDB and I am not going to talk you out of it.

Arc is not transactional. If your hypertables share a consistency boundary with relational data that needs ACID guarantees, keep Postgres. Clustering and high availability are Arc Enterprise features rather than OSS.

License. AGPL-3.0 for the community edition. This is deliberate: it stops cloud providers from repackaging Arc commercially without contributing back. Some enterprise legal teams bar AGPL outright, and if yours does, that does not end the conversation. Arc Enterprise is commercially licensed, which removes the copyleft obligation entirely. If AGPL is the only thing blocking an evaluation, it is a licensing conversation rather than a disqualification, and it is one we have regularly. Talk to us.

TimescaleDB migration path. The best-documented path on this list, because we wrote it. Export hypertables to CSV, load with a single curl command, and translate queries. time_bucket() is identical on both sides. last(value, time) becomes arg_max(value, time) and first() becomes arg_min(). Hypertable creation and retention policies have no equivalent because Arc is schema-on-write with time-based partitioning by default. The full playbook is in Migrating from TimescaleDB to Arc, and there is a migration landing page with the SQL mapping table.

Best for. Analytical workloads on time-series data where you want SQL depth and portable storage, and where transactions are not a requirement.

Try it. Arc runs in a single container:

docker run -d -p 8000:8000 ghcr.io/basekick-labs/arc:latest

Decision matrix

No option wins every row. The right answer depends on which row you are optimizing for.

Migration paths

The storage engine is rarely the hard part of leaving TimescaleDB. The hard part is everything built around it: dashboards, alerts, queries embedded in application code, and the runbooks your on-call team trusts at 3am.

A few principles that hold regardless of destination:

Inventory your TSL dependencies first. Before anything else, list which TSL-only features you actually use: continuous aggregates, retention policies, Hypercore compression, advanced hyperfunctions. That list is your true migration scope, and it is usually larger than people expect.

Migrate ingestion before queries. Dual-write to both databases and validate that data lands correctly. Compare query results across overlapping time windows before you trust anything.

Continuous aggregates are the expensive part. Every destination on this list handles them differently: materialized views plus a scheduler, engine-native rollups, or scheduled queries. Budget for this specifically rather than folding it into "query rewriting."

Decommission last. Keep TimescaleDB running through at least one full retention cycle after cutover. Running two databases for 60 days is cheaper than discovering a missing edge case after you dropped the old one.

What changed in 2026

• TimescaleDB 2.29.0 dropped PostgreSQL 15 support, leaving 16, 17, and 18.
• Recent releases delivered real vectorization work: vectorized filters, bloom filter optimization with up to 160x speedups on some UPDATE and DELETE patterns, and CASE expression vectorization.
• Tiger Data's product narrative moved substantially toward Agentic Postgres, pgai, and pgvectorscale.
• Supabase deprecated the extension for Postgres 17 projects, pointing users to pg_partman.
• Multi-node distributed hypertables remain deprecated, so horizontal scaling is still application-level sharding.

How to choose

1. Is your pain licensing, cost, or one missing feature? Try staying on Postgres first. It is the cheapest experiment.
2. Do you need ACID transactions on this data? Stay on Postgres. Nothing else here gives you that in the sense you mean.
3. Is it really a metrics workload? VictoriaMetrics, and you will be happy.
4. Billions of rows, aggregation-dominated, with cluster operations capacity? ClickHouse.
5. Analytical SQL depth on data you want to keep in an open format? Arc.

And do not pick a database from a blog post, including this one. Shortlist two, run a two-week POC each on your real data at your real cardinality with your real queries, and measure sustained ingest rather than peak, p99 on the queries you actually run, and compression on your own data. Every vendor multiplier in this post, mine included, is marketing until you reproduce it.

FAQ

Is TimescaleDB still a good choice in 2026? Yes, for the right workload. If you need Postgres transactions alongside time-series data, or your team's Postgres expertise is a real asset, it remains the sensible default. It is also actively developed, with 2.29.1 released in August 2026.

Is TimescaleDB open source? Partly. The Apache 2.0 edition covers basic hypertables and core hyperfunctions. Hypercore, continuous aggregates, retention policies, and job scheduling are under the Tiger Data License, which is source-available and prohibits offering the software as a service. Self-managed use is free.

What replaced multi-node hypertables? Nothing built in. Distributed hypertables were deprecated after 2.13, so horizontal scaling means application-level sharding you build yourself, or moving to a database with native distribution.

Can I keep using time_bucket() after migrating? It depends on the destination. Arc supports time_bucket() with the same name and the common single-interval signature, so straightforward calls carry over unchanged; if you rely on the origin or offset parameters, or on time_bucket_gapfill, check those specifically. ClickHouse and InfluxDB 3 both require rewriting to their own time-bucketing functions.

Does Arc's AGPL license rule it out for enterprises? No. Arc Enterprise is commercially licensed, which removes the copyleft obligation. If your legal team bars AGPL, the commercial license exists precisely for that situation.

What is the lowest-effort migration off TimescaleDB? Staying on Postgres with pg_partman for partitioning. If you are leaving Postgres entirely, Arc has the most direct path because time_bucket() carries over and the SQL dialect is close.

This post will be updated quarterly. Last updated August 2026. If something here is wrong or out of date, tell me on GitHub or in Discord.

Related reading:

• Arc vs TimescaleDB on ClickBench
• Migrating from TimescaleDB to Arc
• 6 Best Time-Series Databases in 2026
• 5 InfluxDB Alternatives in 2026
• Parquet vs Proprietary Formats

Explore Arc:

• Compare Arc vs TimescaleDB
• Migrate from TimescaleDB
• Arc documentation
• Star Arc on GitHub

About the author. I am Ignacio Van Droogenbroeck, founder of Basekick Labs and an ex-InfluxData engineer. I have been working with time-series data since 2018. I built Arc because I believe telemetry infrastructure should be built on portable, columnar formats rather than proprietary engines. TimescaleDB is a good product built by good engineers, and for teams that need Postgres transactions it is a better answer than mine. If your workload is analytical and your data outlives the database you put it in, I would like you to try Arc.