InfluxDB vs TimescaleDB vs QuestDB vs VictoriaMetrics

You have spent four chapters of Build 21 building a mental model of how a time-series database actually works — time-partitioned chunks, columnar layout inside chunks, delta + Gorilla compression, continuous aggregates, retention tiers ending in S3. That model is the foundation. But none of it tells you which TSDB to actually install on Monday morning. The four serious open-source contenders solve overlapping problems with very different design philosophies, and the right answer depends as much on what your team already knows and runs as it does on the raw numbers in a benchmark.

This chapter is the one that closes Build 21. It gives you the four products side by side, the criteria that should drive the choice, and a worked example of an Indian fintech doing the evaluation end to end. By the end you should be able to walk into a room, listen to your team describe their workload and existing stack for ten minutes, and confidently say "that one, here is why."

The four contenders, at a glance

The four products exist because they each made a different bet about which axis matters most. Understanding the bet is more important than memorising feature lists, because the bet determines what is hard to change later.

The diagram captures the four design bets in one frame. Read the row labelled "Bet" carefully — it is the most important row, because a product's bet decides the shape of every later trade-off. Why the bet matters more than the feature list: features can be added, but a foundational bet cannot. InfluxDB chose its own query language because it bet that a TSDB-native syntax would be more expressive than SQL for time math; you cannot turn that bet into "we are SQL-first" without rewriting the engine. TimescaleDB chose to ride Postgres because it bet that SQL familiarity outweighs raw throughput; that bet caps single-node ingest at Postgres's ceiling forever. QuestDB chose Java with off-heap memory and tight CPU loops because it bet that single-node throughput is the differentiator; that bet pays off until you outgrow one box. VictoriaMetrics chose Prometheus wire-compatibility because it bet the metrics ecosystem had already standardised; that bet locks it out of mixed workloads where you also want to query orders, users, accounts.

InfluxDB — the established TSDB-first product

InfluxDB is the database most people think of first when they hear "time-series database", because it has been carrying that flag since 2013. It is written in Go, ships as a single binary, and is engineered around a custom storage engine called TSM (Time-Structured Merge tree) that is essentially an LSM with time as the primary sort key, plus aggressive Gorilla-style compression on the value columns.

The query language is Flux, a functional pipeline language that looks like a unix pipe: from(bucket:"telemetry") |> range(start: -1h) |> filter(fn: (r) => r._measurement == "cpu") |> aggregateWindow(every: 1m, fn: mean). It is genuinely expressive — once you internalise the pipeline model, certain queries that are clumsy in SQL become natural — but it is also genuinely a new language with its own learning curve. The older InfluxQL is still supported and looks SQL-ish, but it is a subset and not the recommended path going forward. InfluxDB v3 (the current major version, released over the last two years) is a substantial rewrite on top of Apache Arrow and the DataFusion query engine, and it adds proper SQL — though the migration story for organisations on v1/v2 is still settling.

Best for: greenfield time-series workloads on a team that has no SQL incumbency to preserve and is willing to invest in learning Flux for the expressive payoff. Companies that already use InfluxDB for IoT, DevOps metrics, or sensor telemetry rarely regret the choice. Companies that come from a Postgres background often do regret it within six months because Flux feels alien.

TimescaleDB — Postgres with time-series superpowers

TimescaleDB takes the opposite philosophical stance from InfluxDB: instead of building a new database, build a Postgres extension that adds the time-series-specific machinery to a database your team already knows. You install the extension, run CREATE EXTENSION timescaledb, and turn a regular table into a hypertable with SELECT create_hypertable('metrics', 'ts'). From the outside, the table looks identical — same INSERT, same SELECT, same joins to other tables, same foreign keys, same Postgres operators. Underneath, TimescaleDB transparently splits the table into time-partitioned chunks, adds chunk-level pruning to the planner, exposes time_bucket() and continuous aggregates, and (in newer versions) compresses old chunks columnar-style.

The advantage is enormous and obvious: you keep everything Postgres gives you. Window functions, recursive CTEs, JSONB columns, PostGIS for geospatial, foreign data wrappers, pg_stat_statements, pgBackRest, your existing connection poolers, your existing migration tools, your existing ORMs. You can join the time-series hypertable to a regular relational accounts table in one query without an ETL hop. Why this matters in real life: most "time-series workloads" in the enterprise are actually mixed — telemetry that needs to be joined to user metadata, transactions that need to be joined to merchants, sensor readings that need to be joined to device inventories. A pure TSDB forces you to denormalise heavily or to join in application code; TimescaleDB lets you write the natural SQL.

The disadvantage is the inherited ceiling. Postgres on a well-tuned single node tops out somewhere between 50K and 120K row inserts per second, depending on hardware, fsync settings, batch size, and how aggressive you are with synchronous_commit. TimescaleDB inherits that ceiling because every insert still goes through Postgres's MVCC machinery, WAL, and visibility map. You can scale by sharding (Timescale's multi-node feature) or by separating writes from reads with replicas, but the operational complexity grows quickly.

Best for: teams already running Postgres as their primary OLTP store, with mixed workloads where the time-series data needs to be joined to relational data, and where the throughput requirement is in the tens of thousands of writes per second rather than the millions.

QuestDB — the throughput champion

QuestDB is the youngest of the four and the one with the most aggressive performance bet. It is written in Java but uses off-heap memory and tight, branch-prediction-friendly inner loops to bypass most of the JVM's garbage collector overhead. The on-disk layout is straightforward columnar — one file per column per partition — and the ingest path is engineered to convert incoming rows into columnar appends with minimal copying. The published single-node benchmarks regularly post 1–4 million rows per second on a single commodity server, which is roughly 10× what TimescaleDB does and 4–8× what InfluxDB does on equivalent hardware.

The query language is SQL with time-series extensions like SAMPLE BY 1m FILL(LINEAR) and LATEST ON ts PARTITION BY symbol, which are concise and well-designed for time-series patterns. Crucially, QuestDB also speaks the InfluxDB Line Protocol (ILP) on its ingest port, so existing InfluxDB clients (Telegraf, the official InfluxDB SDKs) can write to QuestDB unchanged. That is a deliberate "easy switch from InfluxDB" story.

The trade-offs are real. The ecosystem is smaller — fewer third-party connectors, fewer Stack Overflow answers, fewer hosted offerings outside QuestDB's own cloud. Clustering and replication are still maturing; for production high-availability you usually run a single primary with read replicas and accept some operational overhead. The community is active and growing fast, but it is not yet the size of Influx's or Timescale's.

Best for: workloads where single-node throughput is the deciding factor — financial market data (ticks, order books, trade execution telemetry), industrial IoT at scale, or anywhere a single Indian fintech node is being asked to absorb hundreds of thousands of writes per second from a fleet of payment terminals.

VictoriaMetrics — Prometheus, but cheap and at scale

VictoriaMetrics solves a very specific problem: Prometheus is wonderful, but its single-node TSDB caps out around 15 days of retention before disk and RAM become painful, and it does not shard. VictoriaMetrics is a Go engine that speaks the same wire protocols (the /api/v1/write remote-write endpoint, the /api/v1/query query endpoint, the same scrape format), supports PromQL plus a strict superset called MetricsQL, but uses a much more aggressive columnar storage layout with better compression — typically 10× smaller on disk than Prometheus for the same data. It runs as either a single binary (the simplest deployment of the four) or as a cluster of three components (vmstorage, vminsert, vmselect) for horizontal scaling.

The ergonomics for an existing Prometheus shop are essentially zero-friction. You point Prometheus's remote_write at VictoriaMetrics, change Grafana's data source from Prometheus to VictoriaMetrics, and every existing dashboard and alert keeps working. Why this matters: in practice, the painful part of switching databases is rarely the database itself — it is the migration of dashboards, alert rules, runbooks, and operator muscle memory. VictoriaMetrics deliberately makes that migration cost zero by being indistinguishable from Prometheus on the wire. That is its single biggest selling point and the reason adoption has been so fast in observability shops.

The trade-off is that VictoriaMetrics is metrics-focused. There is no SQL surface; you cannot easily store and query non-metric time-series data (logs, traces, business events). You cannot join to relational tables. The data model is the Prometheus data model — a name, a set of labels, a sequence of (timestamp, double) samples — and that is it. Within that model VictoriaMetrics is excellent. Outside it, you need a different tool.

Best for: organisations that have already standardised on Prometheus + Grafana for observability and have outgrown vanilla Prometheus's single-node store, either because retention needs are now in months/years or because the volume needs sharding.

The feature matrix

The previous four sections gave you the prose. The matrix below gives you the at-a-glance summary you can hand to a sceptical colleague.

A few things in this matrix deserve commentary because they are easy to misread. Compression ratio is wildly schema-dependent — VictoriaMetrics's 70× is achievable only on stationary, low-cardinality metrics where Gorilla compression eats the value column whole; on high-churn, high-cardinality data the ratio collapses toward the others. Write throughput is per node and assumes batching is enabled — single-row inserts halve every number in that row. Query latency for the "1h scan" assumes the chunks are warm in OS page cache; cold-cache numbers are 5–10× worse for all four.

The decision tree

The matrix tells you what each system can do. The tree below tells you which one to pick. It is short on purpose.

The tree makes the implicit assumption that the cheapest migration is the one you do not have to do. That is why the first two questions are about what you already run. Why this is the right framing: the database itself is rarely the bottleneck. The bottleneck is dashboards, alert rules, on-call runbooks, integration code, the team's mental model. A database that is technically 30% faster but requires you to throw away three years of dashboards is a worse choice than a slightly slower database that lets you keep them. Choose the database that minimises total migration cost, not just storage cost.

For completeness, here are the others you might see in a comparison post but did not make the four-way cut: Prometheus itself (the original; great for what it does, but limited storage), Apache IoTDB (IoT-focused, popular in the China market, niche elsewhere), ClickHouse (general-purpose OLAP that happens to be excellent at time-series, often the right answer when your TS volume is genuinely huge or you also want general analytics), and AWS Timestream (managed-only, AWS-only, useful when you are deeply committed to AWS and want zero ops).

Worked example — an Indian fintech makes the call

A worked example is worth more than another paragraph of abstract advice. The fintech below is composite — a stand-in for several real companies — and the numbers are realistic for an Indian payments company at Series B/C scale.

The case study illustrates the most important lesson of the chapter: the best TSDB for your team is almost always the one that requires you to throw away the least. A 4× throughput advantage is wonderful in a benchmark and irrelevant if it costs three months of dashboard rewrites.

Going deeper

The convergence problem

Look at the four products with a five-year horizon and a striking pattern emerges: they are converging. InfluxDB v3 added SQL on top of Apache Arrow, eroding TimescaleDB's "we have SQL, they don't" advantage. TimescaleDB added columnar compression on old chunks, eroding InfluxDB's "we are columnar, they aren't" advantage. QuestDB added an InfluxDB Line Protocol ingest port, eroding InfluxDB's "we own the metrics-ingest protocol" advantage. VictoriaMetrics added MetricsQL extensions that reach toward what SQL gives you, eroding the "you can't do complex analytics in PromQL" objection.

This convergence is rational — each product is racing toward the union of features the others have — but it creates a problem for the buyer: the products are getting harder to differentiate on raw capability, which means the differentiation is shifting toward ecosystem and ergonomics. That is exactly why the decision tree above is keyed on what you already run rather than on raw feature comparison. The capability gaps are closing; the ecosystem gaps are not.

When the answer is "none of the above"

There are three workload shapes where none of the four is the right choice, and you should know them so you do not reach for a TSDB by reflex.

Shape 1: heavy multi-dimensional analytical queries on time-series data. If your queries look like "top 10 merchants by failure rate, grouped by region and payment method, over the last 90 days, with year-on-year comparison" — that is fundamentally an OLAP workload that happens to have a timestamp. ClickHouse will outperform any of the four TSDBs on this shape because its query planner is built for wide aggregates, not for the narrow time-range scans the TSDBs optimise for.

Shape 2: very low write rates with very high cardinality. If you are storing per-user activity timelines for a billion users with sparse writes per user, the TSDB design assumptions (high write rate, low-to-medium cardinality on tags) work against you. The chunk count balloons, compression underperforms, and you would be better served by a wide-column store like Cassandra or ScyllaDB with explicit time partitioning at the application level.

Shape 3: transactional time-series. If your "time-series" data needs full ACID transactions across multiple rows — for example, a financial settlement system where a batch of related ticks must be inserted atomically and visible to readers atomically — the eventually-consistent ingest paths of most TSDBs are wrong. TimescaleDB is the only one of the four that gives you full Postgres ACID semantics, and even there you have to be careful about chunk boundaries.

The managed vs self-hosted question

A separate axis the chapter has touched on but not stressed: every one of these four has a hosted offering, and for many teams the hosted offering is the right answer regardless of the technical comparison. InfluxDB Cloud runs on AWS, Azure, and GCP with both pay-per-use and dedicated tiers. Timescale Cloud runs on AWS only but is the most mature of the managed offerings (Timescale the company has been operating it for years). QuestDB Cloud is the newest, AWS-only at the time of writing, with a smaller catalogue of regions. VictoriaMetrics does not have a first-party cloud — there are several third-party managed VM offerings (Aiven, Grafana Cloud's metrics tier is partially built on it).

For an Indian team the managed-vs-self-hosted question often gets resolved by data residency: if the data must stay in India for regulatory reasons (RBI-regulated financial data, healthcare data under DISHA), and the managed offering does not have a Mumbai region, the question answers itself. Self-hosted on EKS in ap-south-1 is the only option. Why this matters more in India than in the US: Indian data residency regulations have tightened steadily over the last five years, and the cost of a regulatory misstep — RBI restrictions on a payments company, for example — dwarfs any operational saving from a managed service. The default for any Indian fintech evaluating a TSDB should be "self-hosted in ap-south-1 unless we have an explicit reason to do otherwise." That immediately favours TimescaleDB, QuestDB, and VictoriaMetrics, all of which run cleanly on EKS, and slightly disfavours managed-only offerings like AWS Timestream that have historically had patchy India coverage.

The closing thought of Build 21

You have spent five chapters of Build 21 building up the picture: what makes time-series workloads different (ch.164), how time-partitioned columnar storage exploits that (ch.165), how downsampling and continuous aggregates make dashboards fast (ch.166), how retention tiers push old data to S3 cheaply (ch.167), and now how to pick the actual product (ch.168). The throughline is that time-series is a third database shape — neither OLTP nor OLAP — and the tools that win do so by exploiting the workload's peculiarities ruthlessly. Whether you pick InfluxDB, TimescaleDB, QuestDB, or VictoriaMetrics, you are picking a different combination of those exploits, packaged with a different ecosystem and a different operational model. Pick on ecosystem first, capabilities second, and you will rarely regret it.

Build 22 starts next with a different beast entirely: in-memory databases, where the storage hierarchy is inverted and Redis sits at the centre.

References

1. InfluxDB documentation — official docs covering the storage engine, Flux query language, and v3 architecture.
2. TimescaleDB documentation — official docs on hypertables, continuous aggregates, and compression.
3. QuestDB benchmarks and documentation — official docs and the published time-series benchmark suite results.
4. VictoriaMetrics documentation — official docs on the storage engine, MetricsQL, and the cluster vs single-node deployment models.
5. DB-Engines ranking — Time Series DBMS — independent popularity tracker that gives a useful proxy for ecosystem size and momentum.
6. Time-series benchmark suite (TSBS) — the open-source benchmark harness that most of the published TSDB comparisons use; you can reproduce the numbers in this chapter on your own hardware.