QuestDB

What it is

QuestDB is a column-oriented time-series database you run yourself, queried in SQL with a handful of extensions that exist because generic SQL handles market data badly:

• ASOF JOIN matches each row to the most recent row in another table at or before its timestamp — trades to the quote that was live when they printed — with an optional TOLERANCE clause that rejects a match too stale to mean anything. In Postgres that is a lateral subquery per trade, or a window function over a union of both tables.
• LT JOIN is the same, strictly earlier: what you want when the quote update and the trade share a timestamp and you must not see the quote the trade caused.
• SAMPLE BY 5m builds bars, with calendar or first-observation alignment, a time zone and FILL(PREV | LINEAR | NULL | NONE) for empty buckets — in place of date_trunc, GROUP BY and a generated series to find the gaps.
• LATEST ON ts PARTITION BY symbol returns the last row per instrument without the DISTINCT ON or window-function trick, and stops scanning once it has found one row per symbol.

Ingestion is built for feeds, not transactions: rows arrive out of order and are merged into place, tables and columns are created from the first row, and retried writes can be deduplicated on commit. Version 10.0.0, released 6 August 2026, introduced QWP, a binary columnar WebSocket protocol carrying ingest and query results on the HTTP port; InfluxDB Line Protocol over HTTP or TCP and the Postgres wire protocol still work and are now documented as compatibility protocols. The vendor's own figure is "over 8M rows/sec per server, even through dedup and out-of-order indexing" — QuestDB's benchmark, not an independent one.

Pricing

Two products, one engine. The open-source build is Apache-2.0, costs nothing at any scale, and that is the whole of it: single instance, community support, an admin user plus one configurable read-only user, basic auth over unencrypted transport. Enterprise adds replication with sub-100ms failover, read replicas, TLS on every protocol, column-level RBAC, SSO, audit logs, incremental snapshots to object storage, point-in-time recovery and hot/cold tiering to Parquet and Iceberg on S3, Azure Blob or GCS under the same SQL. Its price is not published — the site has no pricing page at all, only an Enterprise contact form and a trial of unstated length — and there is no self-serve managed tier to fall back on.

Data & coverage

QuestDB ships no market data of any kind. It is storage and a query engine; the ticks are yours to source and yours to load.

Integrations

First-party clients for Java, C/C++, Rust, Python, .NET and Go on the new protocol, Node.js on ILP, PHP and R through PGWire. REST endpoints cover query to JSON, export to CSV or Parquet, and CSV upload. The bundled Web Console is a query editor with Jupyter-style notebooks, nine chart types including candlestick, and dashboards that refresh on a schedule; its AI assistant writes and explains SQL on your own OpenAI or Anthropic key, which stays in the browser. QuestDB also publishes an MCP server — @questdb/mcp-server-questdb on npm, Apache-2.0, 0.4.0 as of 20 August 2026 — giving a coding agent schema access, SQL execution and notebook building.

Limitations

• No DELETE. Rows leave by dropping or expiring a partition via TTL, not by predicate. HAVING, OFFSET, DISTINCT ON, ON CONFLICT and correlated subqueries in WHERE are also absent, and cursors are forward-only — enough Postgres compatibility to connect, not enough to port a schema.
• The open edition is one machine, with no replication, failover, read replicas or tiered storage; backups are full and local and recovery is from the last one. It also does no encryption on any protocol, PGWire included — on an untrusted network that means a proxy or Enterprise.
• Compression is somebody else's job: the documented route is ZFS with LZ4 or zstd underneath, and no ratio for tick data is published.
• It is a database to operate. Production needs ulimit -n and vm.max_map_count raised to 1048576 or you hit errno=24 and errno=12 under load, NVMe or 7000+ IOPS of network storage, 8GB of RAM minimum, and a filesystem that is not NFS — that one is explicitly unsupported.
• LATEST ON partitioned by more than one column scans the whole table and degrades on hundreds of millions of rows. TOLERANCE accepts nanoseconds through weeks, but not months or years.
• Enterprise pricing is unknowable before a sales call, and there is no self-serve managed plan.

Alternatives

ClickHouse if the workload is wide analytical scans rather than joins on time, and you accept writing the as-of logic yourself. TimescaleDB if being actual Postgres — extensions, transactions, DELETE, the ecosystem — matters more than time-series syntax. kdb+ if the budget exists and the requirement is single-digit microseconds. DuckDB over Parquet files if the data fits on one machine and nothing streams in live.