QuestDB

QuestDB is an open-source time-series database designed for blazing-fast ingestion and low-latency SQL analytics over time-stamped data. Writes land durably in a Write-Ahead Log and are asynchronously applied into a native, column-oriented storage format partitioned by time, with cold partitions optionally tiered out to Parquet on object storage — giving a single table both hot ingestion speed and cheap long-term analytical storage without a separate ETL pipeline.

The core engine is implemented in zero-garbage-collection Java and C++, with native C routines providing SIMD-accelerated scans and a Rust crate handling Parquet encode/decode. Its SQL layer extends standard SQL with time-series-native operators — ASOF JOIN, WINDOW JOIN, HORIZON JOIN, SAMPLE BY, and LATEST ON — and includes a purpose-built JIT compiler that turns hot WHERE-clause filters into native machine code at query time, an optimization most SQL engines skip entirely.

QuestDB speaks multiple protocols out of the box: the InfluxDB Line Protocol for high-throughput streaming ingestion, the PostgreSQL wire protocol so existing BI and monitoring tools connect without modification, a REST API for CSV import and queries, and a bundled web console for interactive SQL. Purpose-built finance functions (mid-price, weighted mid-price, spread, level-two order-book price) reflect heavy use in capital markets, alongside broader adoption for IoT telemetry, real-time dashboards, and monitoring.

Licensed under Apache 2.0, the project has been in continuous development since 2014, ships frequent releases, and maintains a separate closed-source QuestDB Enterprise product for teams needing HA, multi-primary ingestion, and RBAC on top of the same open engine.

What You Get

• Multi-tier storage engine: WAL-backed ingestion, native columnar partitions, and optional Parquet tiering on object storage in a single table.
• Time-series SQL extensions: ASOF JOIN, WINDOW JOIN, HORIZON JOIN, LATEST ON, and SAMPLE BY for downsampling and time-aligned joins standard SQL lacks.
• Multiple ingestion paths: InfluxDB Line Protocol for high-throughput streaming writes, the PostgreSQL wire protocol, and a REST/CSV import API.
• A JIT-compiling SQL engine that compiles hot WHERE-clause filters to native machine code and runs vectorized, SIMD-accelerated scans.
• A built-in web console for ad-hoc SQL queries, schema browsing, and CSV import without external tooling.
• Finance-specific SQL functions (mid-price, weighted mid-price, spread, level-two order-book price) for capital-markets analytics.

Common Use Cases

• Ingesting and querying high-frequency financial market data (tick trades, order books, OHLC bars) with ASOF JOIN for point-in-time analysis.
• Storing IoT and sensor telemetry with high-cardinality tags and evolving schemas, adding columns on the fly during ingestion.
• Powering real-time dashboards and monitoring in Grafana or Superset via the PostgreSQL wire protocol or native Grafana plugin.
• Feeding AI coding agents and automated data pipelines with time-series analytics through the QuestDB agent skill and standard SQL/REST interfaces.
• Replacing a general-purpose relational database for time-stamped event data where SAMPLE BY downsampling and window joins simplify queries.

Under The Hood

Architecture Execution starts in Bootstrap, which parses configuration and environment, after which ServerMain constructs a CairoEngine and initializes the ServerConfiguration that wires file paths, security context, and factory providers; a WorkerPoolManager then schedules background jobs (WAL apply, column purge, telemetry) across dedicated thread pools, decoupling ingestion, compaction, and query execution. The storage layer (cairo package) implements a multi-tier engine: writes land in a Write-Ahead Log (cairo/wal — WalWriter, WalReader, sequencer) before being asynchronously applied into native column files partitioned by time, with further tiering out to Parquet on object storage, so ingest durability is decoupled from compaction. The SQL layer (griffin) compiles queries through an ExpressionParser/FunctionParser into a RecordCursorFactory tree, and the jit package can compile hot WHERE-clause filters to native machine code at runtime — a step most SQL engines skip. Network protocols (cutlass: http, pgwire, line, parquet) sit above this shared query/storage core, so ILP ingestion, Postgres wire clients, and the HTTP console all resolve to the same CairoEngine instance; native C code supplies platform-specific SIMD routines invoked via JNI, and a separate Rust crate handles Parquet encode/decode. Because nearly every subsystem operates on TableToken/TableWriter handles issued by the engine, a change to that core abstraction would ripple through ingestion, SQL functions, and WAL apply jobs alike.

Tech Stack The core engine is Java, built with Maven across a multi-module pom.xml, supplemented by native C for SIMD and bit-manipulation routines invoked through JNI across Linux, macOS, and Windows targets, and a Rust crate for Parquet columnar read/write. The SQL engine includes a hand-rolled JIT compiler for filter predicates. Query interfaces span the PostgreSQL wire protocol for BI-tool compatibility, the InfluxDB Line Protocol for high-throughput ingestion, and an embedded HTTP server serving REST/CSV import plus the bundled web console. There is no external ORM — QuestDB is the storage engine itself, with a bespoke native column format as primary storage and Parquet as a cold/tiered format. Deployment targets include Docker images, a Homebrew formula, and Kubernetes Helm charts, with CI running platform smoke tests, license-compliance checks, and dedicated Postgres-wire compatibility suites across a multi-language build matrix.

Code Quality Testing relies on JUnit with a large hierarchy of shared base fixtures for spinning up in-memory table engines, and the test tree mirrors the main source tree extensively across storage, SQL functions, and network protocols, complemented by a separate SQL logic test suite in Rust. Error handling is centralized through a typed exception hierarchy with explicit, platform-aware error-code mapping rather than swallowed exceptions, and that exception type is deliberately implemented as a flyweight to avoid garbage-collection pressure on the hot path — a performance-driven design choice rather than an idiomatic one. Naming is consistent and descriptive, with explicit nullability annotations throughout, though the codebase intentionally avoids some conventional Java patterns for performance. CI enforces secret scanning, license-compliance checks, coverage instrumentation, and dedicated workflows per wire protocol, reflecting a comprehensive and disciplined testing culture even where a standalone linter config was not evident in the files sampled.

What Makes It Unique QuestDB’s differentiation is architectural rather than a feature checklist: a WAL-to-native-columnar-to-Parquet tiering model lets a single table span hot low-latency writes and cold columnar analytics without a separate pipeline, and its SQL engine includes bespoke time-series join operators not found in general-purpose databases. It compiles WHERE-clause filters to native machine code at query time via its own JIT compiler rather than relying on interpreted expression evaluation, and pushes vectorized, SIMD-accelerated execution down to native code for platform-specific fast paths — a hybrid Java/native runtime that is uncommon among open-source databases. Purpose-built finance functions for order-book analytics show deep specialization toward capital-markets tick data rather than being a generic time-series store.

Self-Hosting

Licensing Model Apache License 2.0 — the QuestDB engine in this repository is fully open, self-hostable, and unrestricted, with no license key required for any feature found in the source.

Self-Hosting Restrictions None found. No license-check, feature-flag-gating, or license-key code exists anywhere in this repository’s source tree.

Enterprise Features Per the README and the project’s Enterprise page, a separate closed-source QuestDB Enterprise product (not included in this repository) adds: high availability and read replicas, multi-primary ingestion, cold storage integration, role-based access control, TLS encryption, native Parquet querying over object storage, and support SLAs with enhanced monitoring.

License Key Required No — nothing in this open-source repository requires a license key.