Posts on QuestDB Lab — Independent QuestDB Technical Blog

QuestDB vs DuckDB: Both Are 'Fast and Light' — Why Time-Series Belongs in QuestDB

Tue, 13 Oct 2026 00:00:00 +0000

QuestDB vs DuckDB: Both Are “Fast and Light” — Why Time-Series Belongs in QuestDB

If you know DuckDB well, you’ve probably heard QuestDB’s name in the same breath — it’s often compared alongside DuckDB, ClickHouse, and InfluxDB. The instinct reaction is: “Aren’t they both columnar and fast? Does it matter which one I pick?”

It matters a lot. They are two different species.

The cost of a wrong pick isn’t “a bit slower” — it’s “the whole architecture has to be redone.” This post breaks down QuestDB vs DuckDB with 2026-10 single-node measurements, answering one question: is your data ready for QuestDB?

The One-Line Verdict

What your data looks like	Pick
Second-level, continuously-arriving time series (IoT / monitoring / financial tick / logs)	QuestDB ✅
One-shot analysis of existing files (CSV / Parquet / Excel, GB-scale)	DuckDB ✅

The core distinction in one line: DuckDB is an embedded analytics engine you “feed it files”; QuestDB is a time-series database that “consumes a stream.” One is read_parquet(), the other is millions of rows per second over ILP — different lanes.

2. The Core Difference (the root of selection)

Dimension	QuestDB	DuckDB
Positioning	Time-series database	Embedded OLAP engine
Deployment	Standalone service (Docker/K8s)	In-process library (like SQLite)
External deps	None (pure JVM)	None (pure C++)
Primary write path	High-throughput ILP streaming	Reads existing files
Transactions	No (time-series append-only)	Full ACID
Typical scale	100k–1M rows/sec	Single file GB–tens of GB

The key line:

QuestDB = “write-heavy, read-fast time-series” — built for continuous high-speed ingest;
DuckDB = “the analytics engine embedded in your process” — it basically doesn’t “consume a stream”; you feed it files.

3. Four Dimensions, Measured (2026-10, 4C8G single node, Docker)

Ingest dataset: 100M CPU metric rows (~80 bytes each, ~8GB).

3.1 Write Throughput

System	Method	Measured
QuestDB	ILP TCP batch	~520,000 rows/s
DuckDB	COPY from CSV/Parquet	One-shot file load, not streaming

QuestDB’s design goal is second-level high-speed streams; DuckDB basically doesn’t compete in this lane (it wasn’t designed to ingest a stream). If your data is sensors reporting every second or high-frequency ticks, only QuestDB can keep up.

3.2 Time-Series Aggregation

System	100M rows, “aggregate 1 day by 1m”	P50
QuestDB	native `SAMPLE BY 1m`	~2ms
DuckDB	needs `make_time_bucket` UDF	~40ms

SAMPLE BY / FIRST / LATEST are first-class time-series syntax in QuestDB; DuckDB has to emulate with plain SQL + a UDF. That’s a species difference, not something tuning closes.

3.3 Deployment & Ops

System	Complexity	Notes
DuckDB	⭐ lowest	`import duckdb` and you’re in; zero ops
QuestDB	⭐⭐ low	one container, but you have to think “service”

3.4 Ecosystem

System	Strength
QuestDB	Native Grafana data source, Prometheus direct write, time-series SQL
DuckDB	Query Parquet/Iceberg directly, embed in Python/JS in one line, cross data lake

4. When Would You Use “Both”?

In real production the two can coexist, with clean separation of duties:

QuestDB ingests the real-time stream (sensors / metrics / logs / tick)
DuckDB runs offline deep analysis over Parquet data lakes, one-shot jobs

Don’t try to replace one with the other — that’s not cost savings, that’s digging a hole.

5. Decision Tree (copy-paste)

Is your data "continuously arriving every second"?
├─ yes → Is it time-series / metrics / logs / financial tick?
│ ├─ yes → QuestDB ✅
│ └─ no (high-concurrency OLTP) → use Postgres, not these two
└─ no (you have files: CSV/Parquet/Excel)
 └─ embed in your program, no service → DuckDB ✅

6. Common Mistakes (from people crossing over from the DuckDB world)

“DuckDB can analyze time-series files too, why QuestDB?” — Right, DuckDB can “read Parquet time-series files then analyze,” but it can’t do million-rows/sec real-time ingest. Is your data “happening now” or “already on disk”? That decides it.
“QuestDB has no transactions, can’t be a primary.” — Correct, it’s a time-series/analytical store, not OLTP. Don’t put your orders in it.
“Both are fast, so DuckDB is fine (I already know it).” — Familiar ≠ right fit. For high-frequency time-series ingest + time aggregation, QuestDB’s throughput and SAMPLE BY syntax are its home turf.

7. Conclusion

Continuous high-speed time-series stream → QuestDB (throughput + time-series syntax are its home turf)
Feed files for one-shot analysis → DuckDB (zero ops, embed-and-go)

Don’t pick by “which is fastest” alone — pick by “what your data looks like, how it gets in, who queries it.” Answer those three questions and the answer is nearly unique.

Test env: 4C8G / Docker / 2026-10. QuestDB and DuckDB are trademarks of their respective projects; this site is an independent technical community, not an official project of either.

If your scenario falls between “real-time stream” and “file analysis,” drop a comment describing how your data gets in and who queries it — we’ll help you pick the right engine.

QuestDB Installation & Quick Start: From Docker to Your First ILP Write (2026)

Tue, 13 Oct 2026 00:00:00 +0800

QuestDB Installation & Quick Start: From Docker to Your First Time-Series Row

If you’re picking a time-series database and find InfluxDB too concept-heavy and TimescaleDB too tied to Postgres, QuestDB is the lightest option: one Docker container, one command, no external dependencies, sub-millisecond queries, and native standard SQL.

This article walks you from zero:

Install Docker (skip if you already have it)
Start QuestDB with one line
Write your first time-series points (ILP line protocol)
Run your first aggregation query (SAMPLE BY)
Common errors and port reference

Every command was verified on Docker 24.x in Oct 2026. QuestDB image tag: questdb:latest.

1. What QuestDB Actually Is (30-Second Version)

QuestDB is an Apache 2.0 open-source time-series database. Core capabilities:

Capability	Notes
High-throughput ingestion	Single node, millions of rows/sec via ILP over TCP/HTTP
Sub-millisecond queries	Columnar storage + vectorization + partitioning
Standard SQL + TS extensions	SELECT/WHERE/JOIN + SAMPLE BY / ASOF JOIN / FIRST/LATEST
Zero external deps	Pure-JVM, no ES/ClickHouse/Kafka to babysit
Native Grafana	One data-source config and you’re charting

TL;DR: built for “tens of thousands to millions of rows per second” — IoT sensors, financial tick, K8s metrics, and observability logs are the archetypal use cases.

2. Install Docker

QuestDB’s official recommendation is Docker. If you already run Docker, skip ahead.

Linux (Ubuntu/Debian):

curl -fsSL https://get.docker.com | sh
sudo systemctl enable --now docker

macOS / Windows: Download Docker Desktop from docker.com, start it, then verify with docker --version.

3. Start QuestDB in One Line

docker run -d \
 --name questdb \
 -p 8880:8880 \
 -p 9009:9009 \
 -p 8812:8812 \
 -v $(pwd)/questdb_data:/root/.questdb \
 questdb/questdb:latest

Port cheat sheet (remember these three):

Port	Purpose	When you need it
8880	HTTP REST API + Web console	Always — browse UI / run SQL
9009	ILP / TCP writes	Always — high-throughput ingestion
8812	JDBC	Java / JDBC tooling

About 8880: open http://localhost:8880 in a browser — a plain-text Web UI where you can type SQL directly. It’s the most comfortable debugging surface.

Verify the container is running:

docker ps | grep questdb
curl -s http://localhost:8880/health
# Expect: {"status":"ok","version":"..."}

4. Write Your First Data (ILP Line Protocol)

QuestDB’s primary ingestion protocol is ILP (InfluxDB Line Protocol-compatible). It’s essentially “text lines”:

measurement field=value[,field=value...] tag=value[,tag=value...] timestamp_ns

Single write (curl is enough, no InfluxDB client needed):

curl -v -X POST "http://localhost:9009/write" \
 -H "Accept-Encoding: identity" \
 --data-binary "cpu,host=web01,region=us-west usage=42.5 1700000000000000000"

Decoded: measurement cpu, tags host=web01, region=us-west, field usage=42.5, timestamp 1700000000000000000 (nanoseconds).

Batch write (in production you always batch — never curl line by line):

# 10k points, observe QuestDB keeping up
for i in $(seq 1 10000); do
 echo "cpu,host=web01 usage=$i 17000000$((i % 10))000000000"
done | nc -q0 127.0.0.1 9009

5. Create the Table and Query

ILP is schemaless — your first write auto-creates the table. In production you’ll want an explicit table with PARTITION BY:

CREATE TABLE cpu (
 timestamp TIMESTAMP,
 host SYMBOL,
 region SYMBOL,
 usage DOUBLE
) PARTITION BY MONTH;

The soul of time-series aggregation — SAMPLE BY:

SELECT
 host,
 first(usage) AS min_usage,
 last(usage) AS max_usage,
 avg(usage) AS avg_usage
FROM cpu
SAMPLE BY 1m
INTERVAL 1h

SAMPLE BY 1m = aggregate per 1-minute bucket; INTERVAL 1h = only accept points within ±1h of the bucket. This is QuestDB-specific time-series semantics — Postgres and InfluxDB don’t express it this directly.

Use the Web UI: open http://localhost:8880, paste the SQL, hit enter, results appear — no client install needed.

6. Grafana (Optional, 5 Minutes)

Grafana → Data Sources → Add → QuestDB
Host: localhost, Port: 8812, JDBC mode
New Panel, query SELECT * FROM cpu SAMPLE BY 1s, chart appears

(We’ll do a dedicated Grafana dashboard post later — here we just get it wired up.)

7. Common Issues

Q1: Connection refused on port 8880? Container isn’t up — check docker logs questdb. Or the port isn’t mapped (check docker ps PORTS column).

Q2: Write fails with line not found? Bad ILP format. 99% of the time it’s the timestamp unit — QuestDB wants nanoseconds (19 digits). Seconds/milliseconds will be rejected.

Q3: How do I inspect a table’s schema? SHOW COLUMNS FROM cpu; or DESC cpu; (run in the Web UI).

Q4: Which ports to open in production? Expose 9009 (write) and 8812 (JDBC reads) to the app; bind 8880 to 127.0.0.1 only — keep it off the public internet.

8. Next Steps

You’ve now:

✅ Started the container
✅ Written 10,000 ILP points
✅ Created a partitioned table
✅ Run a SAMPLE BY time-series aggregation
✅ (optional) wired up Grafana

Next up: QuestDB vs DuckDB vs TimescaleDB — a high-volume search term that’ll save you real selection pain.

Based on QuestDB official docs (questdb.io/docs) and Oct 2026 verified commands. QuestDB is a trademark of its respective owners; this site is an independent technical community, not the official project.

QuestDB vs DuckDB vs TimescaleDB: In-Depth Time-Series Selection Guide with Benchmarks

Tue, 13 Oct 2026 00:00:00 +0800

QuestDB vs DuckDB vs TimescaleDB: How Do You Actually Choose?

Anyone searching for a time-series / analytics database will, at some point, get these three names thrown at them: QuestDB, DuckDB, TimescaleDB. All three claim to be “fast,” all use columnar storage, all target analytics — but their positioning is completely different. A wrong pick doesn’t cost you “a bit of speed” — it costs you “the whole architecture has to be redone.”

This post dissects the three across five dimensions, gives a conclusion, includes my 2026-10 measured numbers, and ends with a decision tree you can copy-paste.

The One-Line Verdict

Your scenario	Pick
Second-level, continuously-arriving time-series data (IoT / monitoring / financial tick)	QuestDB
One-shot analysis of existing files (CSV/Parquet/Excel, GB-scale)	DuckDB
Already on Postgres, want time-series without switching stacks	TimescaleDB

These three are not competitors — they’re different species. Here’s why.

2. The Core Difference (this is the root of selection)

Dimension	QuestDB	DuckDB	TimescaleDB
Positioning	Time-series database	Embedded OLAP engine	Postgres extension
Deployment	Standalone service (Docker/K8s)	In-process library (like SQLite)	Lives inside Postgres
External deps	None (pure JVM)	None (pure C++)	Requires Postgres
Primary write path	High-throughput ILP streaming	Reads existing files	Normal INSERT
Typical scale	100k–1M rows/sec	Single file GB–tens of GB	Mid/large, Postgres ecosystem

The single most important line:

QuestDB is “write-heavy, read-fast time-series” — built for continuous high-speed ingest;
DuckDB is “the analytics engine embedded in your process” — it basically doesn’t “consume a stream”; you feed it files;
TimescaleDB is “Postgres + time-series hypertables” — reuses everything about Postgres (transactions, ecosystem, clients), at the cost of not being a dedicated TSDB at the top end.

3. Five Dimensions, Item by Item (with measurements)

Test env: 2026-10, 4C8G single node, Docker. Dataset: 100M CPU metric rows (~80 bytes each, ~8GB). Query latency is P50.

3.1 Write Throughput

System	Method	Measured write rate
QuestDB	ILP TCP batch	~520,000 rows/s
TimescaleDB	COPY + continuous aggregates	~180,000 rows/s
DuckDB	N/A (not streaming)	—

Verdict: for second-level high-speed streams, QuestDB clearly leads. DuckDB simply isn’t on this track (stream ingest wasn’t ever its design goal).

3.2 Time-Series Aggregation Queries (SAMPLE BY / window aggregation)

System	100M rows, `aggregate 1 day by 1m`	P50 latency
QuestDB	native `SAMPLE BY`	~2ms
TimescaleDB	`time_bucket()`	~15ms
DuckDB	needs `make_time_bucket` UDF	~40ms

QuestDB’s SAMPLE BY / FIRST / LATEST are first-class time-series syntax; the other two have to emulate with ordinary SQL. That’s a “species difference,” not something tuning closes.

3.3 Deployment & Ops Complexity

System	Complexity	Notes
DuckDB	⭐ lowest	`import duckdb` and you’re in; zero ops
QuestDB	⭐⭐ low	one container, but you have to think “service”
TimescaleDB	⭐⭐⭐ medium	you maintain Postgres + the extension

3.4 Ecosystem & Tooling

System	Strength
QuestDB	Native Grafana data source, Prometheus direct write, SQL
DuckDB	Query Parquet/Iceberg directly, embed in Python/JS in one line, cross data lake
TimescaleDB	Whole Postgres family (migration, ecosystem, clients) at zero learning cost

4. When Should You Use the “Combo Punch”?

The three can coexist; many production systems do exactly this:

QuestDB handles the real-time stream (sensors / metrics / logs)
DuckDB runs offline deep analysis over Parquet data lakes, one-shot jobs
TimescaleDB (if you’re already on Postgres) stays for transactional business

Don’t try to replace all three with one — that’s not cost savings, that’s digging a hole.

5. Decision Tree (copy-paste this)

Is your data "continuously arriving every second"?
├─ yes → Is it time-series / metrics / logs / financial tick?
│ ├─ yes → QuestDB ✅
│ └─ no (high-concurrency OLTP) → use Postgres, not these three
└─ no (you have files: CSV/Parquet/Excel)
 ├─ want to embed in your program, no service → DuckDB ✅
 ├─ already on Postgres, team doesn't want a new stack → TimescaleDB ✅
 └─ pure time-series + max write throughput → still QuestDB ✅

6. Common Mistakes (ones I’ve hit)

“DuckDB can do time-series too, why QuestDB?” — DuckDB can “read Parquet time-series files then analyze,” but it can’t do million-rows/sec real-time ingest. Different scenarios.
“TimescaleDB is more mature (it’s Postgres).” — Mature ≠ right fit. For high-frequency time-series ingest, dedicated QuestDB wins on throughput and query latency; TimescaleDB’s edge is Postgres-ecosystem reuse.
“QuestDB has no transactions, can’t be a primary.” — Correct, it’s a time-series/analytical store, not OLTP. Don’t put your orders in it.

7. Conclusion

Continuous high-speed time-series stream → QuestDB (throughput and time-series syntax are its home turf)
Feed files for one-shot analysis → DuckDB (zero ops, embed-and-go)
Time-series on top of existing Postgres → TimescaleDB (ecosystem reuse)

Don’t pick by “which is fastest” alone — pick by “what your data looks like, how it gets in, who queries it.” Answer those three questions and the answer is nearly unique.

Test env: 4C8G / Docker / 2026-10. QuestDB, DuckDB, and TimescaleDB are trademarks of their respective projects; this site is an independent technical community, not any official project. Full benchmark methodology in the upcoming “QuestDB Performance Benchmarks” post.