Top Related Projects
Scalable datastore for metrics, events, and real-time analytics
A time-series database for high-performance real-time analytics packaged as a Postgres extension
Apache Druid: a high performance real-time analytics database.
Apache Pinot - A realtime distributed OLAP datastore
ClickHouse® is a real-time analytics database management system
The Prometheus monitoring system and time series database.
Quick Overview
QuestDB is a high-performance, open-source SQL database designed for time-series data. It offers real-time analytics and is optimized for fast ingestion and querying of large-scale time-series datasets. QuestDB combines SQL with time-series extensions, making it suitable for various applications, including financial markets, IoT, and application monitoring.
Pros
- Extremely fast ingestion and query performance
- SQL compatibility with time-series extensions
- Low resource requirements and efficient storage
- Support for both real-time and historical data analysis
Cons
- Limited ecosystem compared to more established databases
- Fewer advanced features compared to some specialized time-series databases
- Steeper learning curve for users unfamiliar with time-series concepts
- Relatively young project, which may lead to more frequent changes and updates
Code Examples
- Creating a table and inserting data:
CREATE TABLE sensors (
ts TIMESTAMP,
sensor_id SYMBOL,
temperature DOUBLE
);
INSERT INTO sensors
VALUES(systimestamp(), 'sensor1', 25.5),
(systimestamp(), 'sensor2', 22.3),
(systimestamp(), 'sensor1', 26.1);
- Querying time-series data with aggregation:
SELECT sensor_id,
avg(temperature) AS avg_temp,
min(temperature) AS min_temp,
max(temperature) AS max_temp
FROM sensors
WHERE ts >= dateadd('h', -1, now())
GROUP BY sensor_id;
- Using time-series functions:
SELECT ts,
sensor_id,
temperature,
rate(temperature) OVER (PARTITION BY sensor_id ORDER BY ts) AS temp_rate
FROM sensors
WHERE ts >= dateadd('d', -1, now());
Getting Started
To get started with QuestDB:
-
Download and install QuestDB from the official website or use Docker:
docker run -p 9000:9000 -p 8812:8812 questdb/questdb -
Connect to QuestDB using the web console at
http://localhost:9000or use a SQL client with the JDBC driver. -
Create a table and insert data:
CREATE TABLE mytable (ts TIMESTAMP, value DOUBLE) timestamp(ts); INSERT INTO mytable VALUES(systimestamp(), 42.0); -
Query your data:
SELECT * FROM mytable;
For more detailed instructions and advanced usage, refer to the official QuestDB documentation.
Competitor Comparisons
Scalable datastore for metrics, events, and real-time analytics
Pros of InfluxDB
- More mature and widely adopted time-series database with a larger community
- Offers a complete ecosystem with additional tools like Telegraf and Chronograf
- Supports both SQL-like and functional query languages (InfluxQL and Flux)
Cons of InfluxDB
- Can be more resource-intensive, especially for large-scale deployments
- Learning curve for Flux query language can be steep for new users
- Limited support for JOINs and complex queries compared to traditional SQL databases
Code Comparison
InfluxDB query (using Flux):
from(bucket:"example")
|> range(start: -1h)
|> filter(fn: (r) => r._measurement == "cpu")
|> mean()
QuestDB query (using SQL):
SELECT avg(usage)
FROM cpu
WHERE time > dateadd('h', -1, now());
Both databases excel at handling time-series data, but QuestDB focuses on SQL compatibility and high-performance ingestion, while InfluxDB offers a broader ecosystem and more flexible query options. QuestDB may be easier for SQL-proficient users, while InfluxDB provides more built-in analysis functions and a wider range of integrations.
A time-series database for high-performance real-time analytics packaged as a Postgres extension
Pros of TimescaleDB
- Built on PostgreSQL, offering full SQL support and compatibility with existing PostgreSQL tools and extensions
- Automatic partitioning and chunking of time-series data for improved query performance
- Advanced features like continuous aggregates and data retention policies
Cons of TimescaleDB
- Higher resource consumption compared to QuestDB, especially for large datasets
- More complex setup and configuration process
- Steeper learning curve for users not familiar with PostgreSQL
Code Comparison
TimescaleDB (SQL):
CREATE TABLE sensors (
time TIMESTAMPTZ NOT NULL,
sensor_id INTEGER,
temperature DOUBLE PRECISION,
humidity DOUBLE PRECISION
);
SELECT create_hypertable('sensors', 'time');
QuestDB (SQL):
CREATE TABLE sensors (
time TIMESTAMP,
sensor_id INT,
temperature DOUBLE,
humidity DOUBLE
) timestamp(time);
Both databases use SQL for querying and data manipulation, but QuestDB's syntax is more streamlined for time-series operations. TimescaleDB requires an additional step to create a hypertable, while QuestDB automatically optimizes for time-series data with the timestamp(time) clause.
Apache Druid: a high performance real-time analytics database.
Pros of Druid
- More mature project with a larger community and ecosystem
- Supports a wider range of data ingestion methods and formats
- Offers advanced features like multi-tenancy and fine-grained security controls
Cons of Druid
- Higher complexity and steeper learning curve
- Requires more resources and infrastructure to run effectively
- Can be slower for certain types of queries compared to QuestDB
Code Comparison
QuestDB SQL query:
SELECT avg(temperature)
FROM sensors
WHERE location = 'New York'
AND timestamp BETWEEN '2023-01-01' AND '2023-12-31'
Druid SQL query:
SELECT AVG("temperature")
FROM "sensors"
WHERE "location" = 'New York'
AND "__time" BETWEEN TIMESTAMP '2023-01-01' AND TIMESTAMP '2023-12-31'
Both databases use SQL-like syntax, but Druid uses double quotes for identifiers and has a special __time column for timestamps. QuestDB's syntax is closer to standard SQL.
QuestDB is designed for simplicity and high-performance time-series data processing, while Druid offers more flexibility and features at the cost of increased complexity. The choice between them depends on specific project requirements, scale, and the development team's expertise.
Apache Pinot - A realtime distributed OLAP datastore
Pros of Pinot
- Highly scalable and distributed architecture for real-time analytics
- Supports multiple data ingestion methods (batch, streaming, hybrid)
- Rich query language with SQL-like syntax and advanced aggregations
Cons of Pinot
- More complex setup and configuration compared to QuestDB
- Higher resource requirements for distributed deployment
- Steeper learning curve for optimization and tuning
Code Comparison
QuestDB:
SELECT avg(temperature)
FROM sensors
WHERE location = 'New York'
AND timestamp > dateadd('d', -7, now());
Pinot:
SELECT AVG(temperature)
FROM sensors
WHERE location = 'New York'
AND timestamp > DateAdd('DAY', -7, Now());
Both QuestDB and Pinot support SQL-like queries, making it easy for users familiar with SQL to work with either system. The syntax is very similar, with minor differences in function names (e.g., dateadd vs DateAdd). Pinot's query language offers more advanced features for complex analytics, while QuestDB focuses on simplicity and performance for time-series data.
QuestDB excels in single-node deployments and offers excellent performance for time-series workloads. Pinot, on the other hand, is designed for distributed environments and can handle a wider variety of analytical queries across large datasets. The choice between the two depends on the specific use case, scale requirements, and the complexity of analytics needed.
ClickHouse® is a real-time analytics database management system
Pros of ClickHouse
- Highly scalable and distributed architecture, suitable for massive datasets
- Rich set of SQL features and functions for complex analytics
- Extensive ecosystem with various integrations and tools
Cons of ClickHouse
- Steeper learning curve due to its complexity and unique features
- Higher resource requirements for optimal performance
- More complex setup and maintenance compared to simpler databases
Code Comparison
ClickHouse SQL example:
SELECT
toStartOfHour(timestamp) AS hour,
count() AS count
FROM events
WHERE timestamp >= now() - INTERVAL 1 DAY
GROUP BY hour
ORDER BY hour
QuestDB SQL example:
SELECT
timestamp_sequence(timestamp, 1h) AS hour,
count()
FROM events
WHERE timestamp >= dateadd('d', -1, now())
SAMPLE BY 1h ALIGN TO CALENDAR
Both databases offer SQL support for time-series data, but ClickHouse provides more advanced features and functions, while QuestDB focuses on simplicity and ease of use for time-series analytics. ClickHouse is better suited for large-scale distributed deployments, whereas QuestDB excels in single-node setups with lower resource requirements.
The Prometheus monitoring system and time series database.
Pros of Prometheus
- More mature and widely adopted monitoring system with a large ecosystem
- Supports a wide range of exporters and integrations
- Powerful query language (PromQL) for data analysis and alerting
Cons of Prometheus
- Can be resource-intensive for large-scale deployments
- Limited long-term storage capabilities without additional components
- Steeper learning curve for advanced features and configuration
Code Comparison
Prometheus (Go):
func (h *Handler) serveMetrics(w http.ResponseWriter, r *http.Request) {
metrics.IncrementCounter(metrics.HttpRequestsTotal)
h.metrics.ServeHTTP(w, r)
}
QuestDB (Java):
public class MetricsPublisher implements Closeable {
private final MetricRegistry registry;
private final JmxReporter reporter;
public MetricsPublisher() {
this.registry = new MetricRegistry();
this.reporter = JmxReporter.forRegistry(registry).build();
this.reporter.start();
}
}
Both projects use different languages and approaches for metrics handling. Prometheus focuses on HTTP-based metrics collection, while QuestDB utilizes JMX for reporting metrics in a Java environment.
Convert 
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
English | ç®ä½ä¸æ
QuestDB is the open-source, low-latency time-series database on open formats. It ingests millions of events per second, computes on live data in milliseconds, and keeps years of history queryable. One SQL engine spans ingestion, stream processing, and tiered storage.
The engine is zero-GC Java with C++ and Rust on the hot paths. Data lives in memory-mapped, time-partitioned columns. Queries run across all cores with SIMD and JIT-compiled filters. There are no third-party dependencies on the data path.
Storage is tiered: a parallel write-ahead log, native columnar partitions,
and Apache Parquet. In open source you convert partitions to Parquet with
ALTER TABLE, or create a table in Parquet directly. QuestDB Enterprise
converts cold partitions automatically and tiers them to object storage.
Parquet, Apache Iceberg, and Apache Arrow keep the data open to any tool.
Measured on QuestDB 10.0 over QWP:
| Source | ||
|---|---|---|
| Peak ingestion per instance | 19M rows/sec | QWP vs ILP ingestion benchmark |
| Query results streamed to Arrow | 220M rows/sec | Streaming 500 million rows into Arrow |
| 500M rows streamed | 2.3 s | same post |
| First Arrow batch | 32 ms | same post |
Get started
Use Docker to start quickly:
docker run -p 9000:9000 -p 8812:8812 questdb/questdb
Or macOS users on Apple Silicon can use Homebrew:
brew install questdb
brew services start questdb
questdb start
questdb stop
QuestDB bundles native libraries for Apple Silicon only. On an Intel Mac, use the Docker image above.
For the full walkthrough, start with the quick start guide.
QuestDB Web Console - click to launch demo
New in QuestDB 10.0: the QuestDB Wire Protocol (QWP), one binary columnar protocol for writes and for Arrow reads, plus native arrays and live views in beta. Release notes.
Ingress and egress over QWP
QWP is a binary columnar protocol over WebSocket. The same connection writes rows in and streams query results back out as columns. The Python client returns those columns as Apache Arrow by default, and Rust and C/C++ can enable it with a flag.
On the way in, the QWP vs ILP ingestion benchmark measures 19M rows/sec over the network, and that peak holds from one thousand to one million series. On the way out, Streaming 500 million rows into Arrow measures 220M rows/sec with eight readers, with the first batch after 32 ms and client memory flat however large the result. The QWP overview covers the protocol design.
What QuestDB does
One engine covers the full lifecycle of the data:
- Capture. Ingest millions of ordered and out-of-order events per second without pre-aggregation. Deduplication and out-of-order correction are built in.
- Compute. Transform, enrich, and aggregate events as they arrive. Materialized views aggregate by time slice, many rows in and one row out. Live views run window functions such as indicators, one row in and one row out, on an in-memory tier.
- Query. Run time-series SQL across live and historical data with predictable low latency.
- Retain. Keep the complete record online in native storage and Parquet, queried through the same SQL. Enterprise tiers cold partitions to object storage automatically.
The SQL is standard, extended where time series needs it: SAMPLE BY,
LATEST ON, ASOF JOIN, WINDOW JOIN, HORIZON JOIN, materialized views,
live views, and n-dimensional arrays.
Both queries run on the live demo:
-- 15-minute OHLCV bars for EURUSD, today
SELECT timestamp, symbol,
first(price) AS open,
max(price) AS high,
min(price) AS low,
last(price) AS close,
sum(quantity) AS total_volume
FROM fx_trades
WHERE symbol = 'EURUSD'
AND timestamp IN '$today'
SAMPLE BY 15m;
-- Match each trade to the most recent quote by timestamp
SELECT t.timestamp, t.symbol, t.price, q.bid_price, q.ask_price
FROM fx_trades t
ASOF JOIN core_price q ON (symbol)
WHERE t.timestamp IN '$today';
Where it runs:
- capital markets: tick data, order books, trades, pre-trade analysis and post-trade analytics, with the finance SQL cookbook, finance functions and order book analytics
- aerospace and robotics: flight-test telemetry, fleet data, mission replay
- energy and infrastructure: reactor, turbine, and grid telemetry at full resolution
- AI coding agents, through the agent skills and the MCP server
A time-series engine takes care of what a general database leaves to you: out-of-order data, deduplication and exactly-once semantics, continuous ingest under concurrent queries, bursty load, and schema changes while streaming.
Try QuestDB, demo and dashboards
The live, public demo runs the latest QuestDB release on sample datasets. Scan more than 2 billion rows in milliseconds:
- Trades: live crypto trades with 30M+ rows per month (OKX exchange)
- FX order book: live charts with orderbook FX pairs.
- Trips: 10 years of NYC taxi trips with 1.6 billion rows
We also have some public, real-time demo dashboards using our Grafana-native plugin:
- Real-time crypto trades: executed trades on OKX from more than 20 assets in real time
- FX order book: live depth/imbalance charts for major FX pairs
QuestDB performance vs. other databases
TSBS ingestion at 100,000 hosts with 32 workers on one AWS r8a.8xlarge (32 vCPU, 256 GB RAM). Competitors benchmarked August 2026, QuestDB 9.3.3 on the same instance.
| Engine | Version | Ingestion rate |
|---|---|---|
| QuestDB | 9.3.3 | 8.59M rows/sec |
| ClickHouse | 26.7.5.10 | 1.75M rows/sec |
| TimescaleDB | 2.29.1 | 1.08M rows/sec |
| InfluxDB | 1.12.4 | 541K rows/sec |
The full comparisons, ingestion and queries:
- QuestDB vs InfluxDB
- QuestDB vs InfluxDB 3
- QuestDB vs ClickHouse
- QuestDB vs TimescaleDB
- QuestDB vs kdb+
As always, we encourage you to run your own benchmarks.
AI coding agents
QuestDB works with Claude Code, Codex, Cursor, and any MCP client. There are two ways in.
Run SQL against the database from your agent. Install the QuestDB skill. It teaches the agent QuestDB's SQL dialect and how to inspect a schema. The agent then executes SQL through the REST API.
npx skills add questdb/skills
Prototype in the Web Console. For notebooks and SQL prototyping driven by the agent directly, connect it to the Web Console MCP server.
Setup for each agent is in the coding agents guide.
Connect and integrate
First-party clients
QuestDB clients for ingesting data and running queries over the QuestDB Wire Protocol:
Connect to QuestDB
See the Connect overview for the full picture.
The QuestDB Wire Protocol (QWP) is the native protocol and the recommended
way to talk to QuestDB. It is binary, streams in both directions over a single
connection on port 9000, and covers ingestion and queries through one
connect string. The first-party clients listed above speak it.
QuestDB also speaks compatibility protocols, so existing tooling works unchanged:
- PostgreSQL Wire Protocol
on port
8812: run queries from any Postgres driver such as psycopg, JDBC or pgx, and from BI tools and ORMs. Inserts work too, but slower than QWP. - InfluxDB Line Protocol
on port
9000, for collectors and pipelines that already emit ILP - REST API on port
9000, for HTTP scripting, cURL, and CSV import
For interactive use, the
Web Console
provides a SQL editor, charts, and CSV import on port 9000.
Popular third-party tools
Ingest from:
Query from:
The integrations overview lists the rest.
End-to-end code scaffolds
From streaming ingestion to visualization with Grafana, start with code scaffolds from our quickstart repository.
Configure QuestDB for production workloads
Find our capacity planning to fine-tune QuestDB for production workloads.
QuestDB Enterprise
The QuestDB you already run, hardened for production. Enterprise adds:
- high availability: replication, read replicas, automatic failover
- multi-tier storage at petabyte scale: cold partitions tier automatically to Parquet on object storage and stay queryable in place
- security and governance: role-based access control, TLS, SSO, audit logs
- 24/7 support with a 99.9% uptime SLA
Run it on-prem, as a managed service, or inside your own AWS or Azure account with Bring Your Own Cloud. See the feature comparison and the Enterprise page.
Additional resources
ð Read the docs
- QuestDB documentation: begin the journey
- Product roadmap: check out our plan for upcoming releases
- Tutorials: learn what's possible with QuestDB, step by step
â Get support
- Community Discourse forum: join technical discussions, ask questions, and meet other users!
- Public Slack: chat with the QuestDB team and community members
- GitHub issues: report bugs or issues with QuestDB
- Stack Overflow: look for common troubleshooting solutions
ð¢ Deploy QuestDB
- Official Docker image
- Kubernetes Helm charts
- systemd
- AWS
- Azure
- Google Cloud Platform
- DigitalOcean
- Hetzner
- ZFS compression
- Bring Your Own Cloud (Enterprise)
Contribute
Contributions welcome!
We appreciate:
- source code
- documentation (see our documentation repository)
- bug reports
- feature requests or feedback.
To get started with contributing:
- Have a look through GitHub issues labelled "Good first issue"
- For Hacktoberfest, see the relevant labelled issues
- Read the contribution guide
- For details on building QuestDB, see the build instructions
- Create a fork of QuestDB and submit a pull request with your proposed changes
- Stuck? Join our public Slack for assistance
⨠As a sign of our gratitude, we send QuestDB swag to our contributors!
A big thanks goes to the following wonderful people who have contributed to QuestDB emoji key:
This project adheres to the all-contributors specification. Contributions of any kind are welcome!
Top Related Projects
Scalable datastore for metrics, events, and real-time analytics
A time-series database for high-performance real-time analytics packaged as a Postgres extension
Apache Druid: a high performance real-time analytics database.
Apache Pinot - A realtime distributed OLAP datastore
ClickHouse® is a real-time analytics database management system
The Prometheus monitoring system and time series database.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot