QuestDB

Name: QuestDB
Brand: QuestDB

QuestDB is the open-source time-series database for demanding workloads—from trading floors to mission control.

Est 2019|Valuation $73.2M|Raised $18.1M|45 Ref Customers

LinkedIn 5K|Website|FTEs 30|HQ New York, New York, US

MarketsCloud Databases

Published Oct 15, 2026

01Common complaints

- When a requirement exists for a general-purpose PostgreSQL-compatible database that provides full Postgres semantics across all workloads; QuestDB is a specialized analytics/time-series engine rather than a full relational database replacement. - When transparent enterprise pricing and self-serve procurement are strict procurement criteria; Enterprise pricing is typically provided via sales engagement rather than a public rate card in the sources reviewed. - For metrics/observability workloads where an organization prefers an ecosystem-native toolset; alternatives such as InfluxDB, VictoriaMetrics, or Prometheus-based stacks may be more suitable depending on integration needs. - When a proven, mature distributed OLAP fabric with broad adoption (and a well-documented distributed/replication operational model) is a primary requirement; ClickHouse or Druid may be preferable in such cases. - When strict compliance attestations (SOC 2, ISO 27001) must be publicly available for vendor due diligence; QuestDBs public compliance posture was not clearly documented in the sources used for this report and should be validated with the vendor. - Publicly discussed limitations / concerns - Benchmark methodology concerns are commonly raised in community discussions; benchmark outcomes are sensitive to workload shape, cardinality, and environment. - Community feedback includes questions about distributed scaling, replication, and cluster operations; these should be validated against current documentation and Enterprise feature sets. - Vendor-acknowledged limitations and roadmap - This research set did not retrieve a single canonical limitations or roadmap page with dated commitments. Buyers should request a current architecture overview for HA/distribution and a roadmap for clustering and security/IAM features with target timelines. - Security/compliance gaps - Security certifications were not publicly documented in the accessible sources; enterprise buyers should obtain formal documentation during procurement.

Deal disqualifiers (poor fit)

Requirement for a single system to function as a full-featured OLTP RDBMS with full Postgres semantics, constraints, and a broad extension ecosystem.
Requirement for published security certifications and formal compliance documentation as a procurement prerequisite.
Need for mature, community-validated multi-node replication and clustering without reliance on enterprise licensing or vendor-managed features.

02Why they buy

- SQL-first time-series analytics with Postgres client compatibility - PGWire support allows reuse of many Postgres drivers and client tools. - Vendor-published performance characteristics - Vendor materials and some benchmark reports indicate high ingestion throughput and fast analytical query performance; these claims should be validated with buyer-specific workloads. - Parquet interoperability for data portability - The vendor emphasizes Parquet compatibility as a mechanism for integration with data lakehouse or object-storage tiering strategies. - Areas where competitors have advantages (for balanced procurement evaluation) - TimescaleDB: Postgres ecosystem compatibility and operational familiarity. - InfluxDB: platform-level features and managed offerings for monitoring/observability. - ClickHouse: mature distributed query/replication features and broad OLAP adoption.

03Field reports

- Vendor-published case studies / claims - QuestDB's site and Enterprise page reference examples in capital markets and aerospace, including claims of processing large volumes of events for specialized customers. - Critical evaluation - These are vendor-published claims and should be treated as directional unless the underlying architecture, dataset characteristics, SLOs, and measurement methodologies are disclosed and independently verified. - Performance claims in vendor benchmarks - The vendor publishes comparisons that show ingestion and query performance advantages versus some alternatives. - Critical evaluation - Vendor-published benchmarks can inform hypotheses but should be reproduced using the buyer's own schema, cardinality, out-of-order characteristics, retention, and query mix to determine applicability. - Community discussions highlight common benchmark pitfalls and recommend buyer-led validation. - Independent benchmark/analysis signals (mixed) - Some third-party evaluations and academic benchmark literature include QuestDB in comparative studies; results vary depending on workload definition and environment.

Customer Testimonials

- Review platform availability caveat - Gartner Peer Insights access limitations prevented retrieval of a QuestDB-specific review page in this research set. - G2 (review platform) - A QuestDB reviews page exists on G2; this research set did not capture full-text review quotes for independent verification within this report. - TrustRadius (review platform) - TrustRadius has a QuestDB presence and comparison pages. Verified review excerpts were not retrieved in full by this research set. - Community (Reddit) — examples summarized - Release announcements and feature discussion - Community threads discuss release notes and new features (e.g., indexing for SYMBOL columns and changes to time-series fill semantics). These are product-community posts and vendor announcements rather than independent reviews. - Benchmark skepticism and methodology concerns - Community discussions include skepticism about database benchmark methodology and caution about generator characteristics, warm vs cold cache effects, and workload representativeness. - Feature-set expectations - Some forum commenters contrast QuestDB's speed-focused design with PostgreSQL's broader SQL feature set and transactional semantics, noting potential trade-offs when adopting QuestDB as a primary relational store. - Scalability and clustering concerns - Community comments include concerns about partitioning, replication, and multi-node distribution in some deployment scenarios; these statements require validation against current product capabilities and enterprise offerings. - Common reasons customers appear to choose QuestDB (triangulated from vendor positioning and community discussion) - SQL-first querying and compatibility with Postgres tooling via PGWire. - High ingestion throughput and fast analytical queries on append-only or append-mostly datasets. - Suitability for finance/time-series patterns (time bucketing, as-of joins, SAMPLE BY semantics). - Common reasons customers might leave / not choose QuestDB (triangulated) - Need for full PostgreSQL semantics, transactional guarantees, or a broader extension ecosystem. - Requirement for out-of-the-box distributed clustering/replication and proven multi-node operational maturity. - Procurement requirements for documented enterprise security/compliance and transparent pricing.

04Best fit

Company sizes

Good fits typically include teams with significant ingestion or query-performance needs:
- Mid-market to enterprise engineering organizations (organizations ranging from small-to-large) running high-ingestion analytics workloads.
- Small quant or engineering teams where a single-node high-performance engine meets requirements.

Industries / verticals

Capital markets, trading, market surveillance.
Aerospace and industrial real-time monitoring.
IoT and telemetry analytics.

Roles and personas

Decision makers: Heads of Data Engineering, Platform Engineering, Quant/Trading Tech leads, and CTOs in data-intensive startups.
End users: Data engineers, quantitative analysts, analytics engineers, and SREs responsible for telemetry analytics.

Pain points the product addresses

Ingestion throughput limitations in general-purpose RDBMS deployments.
Slow ad-hoc time-bucketed analytical queries.
Requirement for SQL querying rather than a proprietary query language.

Qualification criteria (good fit)

Workloads that are append-mostly time-series/event data.
Heavy use of aggregation and time-window queries.
Acceptance that the chosen system is a specialized analytics store rather than a primary OLTP system.

05The pitch

What the product does (core value proposition in objective terms)

- QuestDB is an open-source, SQL-first time-series database designed for high-ingestion, low-latency analytics on event/time-series data (common workloads include market data, observability metrics, industrial telemetry, and machine/agent telemetry). It is optimized for fast ingestion, scans, aggregations, and uses a columnar/time-partitioned storage engine. - It supports the PostgreSQL wire protocol (PGWire) so many Postgres clients can connect, and it supports Apache Parquet to facilitate interoperability and reduce vendor lock-in.

Target market and market positioning

Target users: engineers building real-time analytics pipelines, quantitative/market surveillance systems, telemetry platforms, or any application where append-mostly time-series with analytical queries is the primary workload.
Market positioning: a time-series database that provides SQL support; commonly compared with TimescaleDB (Postgres-based), InfluxDB (metrics-first), and ClickHouse (general OLAP).

Get a comprehensive analysis of QuestDB including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →