QuestDB: Time Series, SIMD, and SQL Without the Pain

If you’ve ever had to crunch through millions of time-stamped rows in a relational database, you know the pain. Normal SQL engines weren’t built for that. They start choking once your WHERE timestamp BETWEEN hits a few hundred million rows, and your query times go from "maybe this will finish" to "let me just fetch another coffee."

That’s where QuestDB comes in. It’s an open source time-series database that treats performance as a first-class feature, not an afterthought. And it does that with some clever low-level tricks — like using SIMD instructions directly in the SQL engine — while still giving you a familiar PostgreSQL wire protocol interface. No new query language to learn.

What It Does

QuestDB is a purpose-built time-series database. You feed it timestamped data — think stock ticks, IoT sensor readings, application logs, or even server metrics — and it lets you query that data with standard SQL. It stores data in columns (columnar storage), which is great for analytical queries over large time ranges. But where it really shines is in the execution layer.

It doesn't just translate SQL into generic operators. It uses hand-tuned, SIMD-accelerated code paths for operations like filtering, aggregation, and joins. That means it can process billions of rows per second on a single machine, without needing a massive cluster.

Why It’s Cool

Here are the things that stood out to me when I dug into the repo:

1. SIMD-accelerated SQL
Most databases treat your CPU like a general-purpose calculator. QuestDB writes assembly-level SIMD loops for common operations. For example, when you filter a column with WHERE price > 100, it can process 32 values at once using AVX-512 or AVX2 instructions. That’s not a theoretical optimization — it’s baked right into the query engine.

2. Multi-tier storage
You can configure hot data on fast NVMe drives, warm data on SSDs, and cold data on object storage like S3. Queries automatically know which tier to hit, and the engine handles the moving of data between tiers. This is huge for operational costs — you don’t have to keep your entire 10TB dataset on expensive flash storage.

3. No weird query language
It speaks PostgreSQL wire protocol. So you can connect QuestDB with your existing tools — Grafana, Python scripts, BI tools, whatever. No need to learn a new dialect. It even supports JOIN across time-series tables, which a lot of time-series databases just skip.

4. Built for ingestion
QuestDB has a line-based ingestion protocol (like InfluxDB’s line protocol) that can handle millions of rows per second. It also supports Kafka Connect, so you can pipe streams directly from Kafka without an intermediary.

5. Compressed storage
It uses a mix of run-length encoding, delta encoding, and dictionary compression. The GitHub README claims 5-10x compression on real-world datasets. I haven’t verified that, but the code is right there if you want to check.

How to Try It

The fastest way is using Docker:

docker run -p 9000:9000 -p 9009:9009 -p 8812:8812 questdb/questdb

• 9000 — Web console (open http://localhost:9000 in your browser)
• 9009 — Ingest endpoint (for line protocol)
• 8812 — PostgreSQL wire protocol (connect with any PostgreSQL client)

Once it’s running, you can start inserting data via the web console, REST API, or ingest protocol. There’s even a sample dataset button in the UI that imports 50 million crypto trade records in seconds. Just click it and start querying.

If you prefer bare metal, they provide a single .jar that runs on any JVM. No dependencies beyond Java 11.

Final Thoughts

QuestDB isn’t trying to replace your OLTP database. It’s a specialized tool for a specific job: time-series analytics at scale, with fast ingestion and low query latency. The SIMD acceleration feels like a genuine differentiator — most databases leave that work to the OS or the JIT compiler, but QuestDB does it explicitly. It’s refreshing to see a project go that deep into hardware optimization without sacrificing developer experience.

If you’re dealing with time-series data and you’re tired of wrangling bloated setups or waiting on slow queries, give it a spin. It might just save you from buying a second server.

Follow us on Twitter: @githubprojects