QuestDB Wants Robots to Trade Data Like Wall Street

QuestDB Moves From Trading Floors to Robot Fleets

QuestDB built its database for trading floors where a dropped nanosecond means a lost trade. That architecture is now being marketed to engineers building robot fleets, rocket telemetry systems, and Physical AI platforms, and QuestDB says the same design that survived capital markets applies to physical systems.

QuestDB spent its first years building a column-oriented time-series database for tier-1 banks, exchanges, and hedge funds across four continents. "QuestDB began in eFX trading. Our team spent decades building low-latency execution and risk engines where dropped messages were unacceptable, latency was measured in nanoseconds, and data volumes reached millions of rows per second," QuestDB said. The company argues that architecture suits physical systems (robots generating millions of distinct sensor series, rockets streaming telemetry, energy plants operating at high cardinality).

Physical AI — general-purpose models controlling machines in the physical world — is absorbing capital at a pace matching the generative-AI boom of 2023. Goldman Sachs projects cumulative humanoid investment to surpass $50 billion by 2030, with the segment potentially reaching $150 billion or more by the mid-2030s and SVB expecting $120 billion in total VC hardware investment by year-end. 2026 has already eclipsed 2025's full-year total.

What QuestDB sells those robots is what it sold trading desks: a database that ingests millions of events per second, computes on live data in milliseconds, and keeps years of history queryable in a single SQL engine. QuestDB reports 19 million rows per second per server ingestion and 220 million rows per second streamed to Arrow. Its SQL extensions — ASOF JOIN, HORIZON JOIN, and array primitives — were built for order-book analytics but map onto spatial-temporal queries in robotics. QuestDB 9.0, released in July 2025, added multi-dimensional NumPy-like arrays, opening a path to storing machine-learning weights alongside telemetry.

QuestDB's production track record spans continents. B3, Brazil's main stock exchange and Latin America's largest, runs QuestDB to process every trade on the world's tenth-largest exchange, over $5 billion in daily volume, QuestDB's data shows. Airbus deploys QuestDB for real-time applications pulling billions of data points each day. Brevan Howard selected QuestDB in July 2026 to power live and historic market data for systematic trading. In 2025, QuestDB shipped 31 releases — 16 open-source and 15 enterprise — delivering up to 100x speedups on production datasets and cutting costs by more than 90 percent on certain workloads, QuestDB's 2025 Year in Review reported.

QuestDB generated roughly $3 million in revenue in 2024, a small team by any measure. Yet the database architectures built for capital markets — where a dropped message is a regulatory violation, not a rounding error — are the ones physical AI demands. Traditional monitoring databases like InfluxDB downsample and tolerate loss. QuestDB's founders built something else, and the physical world is now the proving ground.

No Data Loss: The Trading-Floor Advantage

The gap between QuestDB and traditional time-series databases is not incremental performance — it is a philosophical divide over what happens when data disappears. QuestDB came out of trading floors, where a lost tick means a lost trade, a blown risk limit, or a regulatory violation. InfluxDB was built in 2013 for metrics and monitoring, where a few dropped points on a dashboard are an annoyance, not a catastrophe. As robotics, aerospace, and Physical AI push the same demands onto engineers who have never worked a capital-markets desk, that gap widens.

The architectural roots of this divergence trace to how each database structures storage. InfluxDB creates a separate TSM (Time-Structured Merge) tree for each unique series. At scale — say 100,000 hosts with 10 metrics each — that is one million separate storage structures to maintain, index, and compact. QuestDB stores all data in a single columnar table regardless of cardinality. Adding more hosts simply adds more rows to the same structure. The practical consequence is measurable: QuestDB holds throughput between 7.14 million and 8.59 million rows per second as cardinality scales from 1,000 hosts to 1 million, while InfluxDB v1 falls by almost 5x over the same range. InfluxDB 3 Core, the April 2025 rewrite in Rust built on Apache Arrow and DataFusion, holds a flat 319,000 rows per second regardless of cardinality, roughly 22x slower than QuestDB at the low end.

The loss-tolerance model follows from this architecture. InfluxDB was designed for observability: collect server metrics, downsample over time, and let old data age away. QuestDB treats the full-fidelity operational record as sacred: the newest state available in milliseconds, years of history behind it, one SQL engine across all of it. This requirement made it the choice for those institutions across four continents. Now engineers apply it to telemetry from energy plants, rockets, and fleets of robots, where a gap in sensor data can mean a missed collision-avoidance window or an incomplete flight-record reconstruction.

The benchmark numbers quantify the cost of loss-tolerance. When asked for the latest value across all series, QuestDB answers in 1.7 milliseconds using LATEST ON. InfluxDB v1 takes about a third of a second and v2 takes over half a second, because it must open every series to find the end of each one. On a double-groupby-all query, QuestDB completes in 56.10 milliseconds against InfluxDB v1's about 8.6 seconds, 154x faster. InfluxDB 3 Core takes 54 seconds on the same last-point benchmark. These results reflect the cost of walking a million separate storage structures versus scanning a single columnar table with a JIT-compiled predicate.

InfluxDB 3 Core represents a major architectural shift: a complete rewrite in Rust, Apache Arrow for in-memory representation, DataFusion as the query engine, Parquet for storage, and Arrow Flight for the query protocol. It now speaks SQL and InfluxQL rather than Flux, closing the query-language gap that once favored QuestDB's SQL-native approach. On heavy-aggregation workloads, InfluxDB 3 Core runs several times faster than v1 and v2. But it still holds a flat rate regardless of cardinality, while QuestDB holds 7.1 million to 8.6 million across the full range. The older database retains broader native integrations with monitoring tools and a larger collection of community Telegraf plugins, a genuine advantage for teams already embedded in the Influx stack.

Physical systems generate data irretrievably the moment it is lost. A robot's lidar sweep at 200 hertz cannot be re-sent if dropped; a rocket's telemetry gap during re-entry cannot be backfilled. Traditional IoT monitoring assumes some data loss is acceptable because the purpose is approximate trending. Physical AI assumes every sample matters because the system operates in a closed loop where missing state leads to incorrect actuation. QuestDB's architecture — single-columnar-table ingestion, JIT-compiled filtering across partitions in parallel, sub-millisecond LATEST ON — makes data loss architecturally impossible. InfluxDB's architecture makes data loss tolerable. For an engineer designing the data layer of a robot fleet or an autonomous drone system, that distinction should shape the choice before a single line of code is written.

QuestDB's August 2026 benchmarks show InfluxDB v1 is faster on narrow single-host queries; QuestDB is faster on every query that aggregates across hosts, by a wide margin. QuestDB recommends that teams building something new, where the data will matter, start on QuestDB to avoid a migration later. The trade-offs are real: a smaller ecosystem, limited clustering in the open-source version, and cloud pricing that may exclude smaller teams. But for high-throughput time-series workloads where performance is the deciding factor and every sample counts, the architecture itself makes the case.

The Competitive Countermove

QuestDB's push into robotics and Physical AI has not gone unanswered. The time-series database market is now contested by legacy players who have spent years optimizing for the very workloads QuestDB targets: high-frequency ingestion, low-latency queries, and telemetry at scale. InfluxDB 3 and TimescaleDB have each moved to close the gaps that made QuestDB attractive to capital markets, producing a three-way fight where the winning architecture depends on whether data loss is tolerable.

InfluxDB 3 represents the most aggressive countermove. The platform abandoned its proprietary Flux query language, adopting SQL and InfluxQL instead, erasing the language barrier that had once tilted toward QuestDB's SQL-native approach. Enterprise 3.11 adds bulk import from remote object stores like S3 with configurable concurrency, in-place and incremental backup and restore, and compaction and query performance improvements. New clusters default to Parquet storage, upgradable via the --upgrade-pacha-tree flag, a direct response to QuestDB's open-format strategy. On September 15, 2026, the latest tag for InfluxDB Docker images will point to InfluxDB 3 Core, signaling a decisive migration away from the OSS 2.x line. InfluxDB 3 also claims unlimited cardinality, processing millions of high-resolution signals per second from LiDAR, cameras, and IoT telemetry with unlimited tags, a specification that maps directly onto the sensor-dense workloads of robotics and aerospace.

InfluxDB has positioned itself as an AI-integrated platform. Its MCP (Model Context Protocol) server allows developers to use large language models or agentic AI to query time-series data and manage infrastructure without custom code. The Explorer UI supports natural-language queries, and the Processing Engine runs custom Python logic to detect anomalies and trigger events downstream. InfluxDB 3 connects to tools like Claude Desktop, making time series data as easy to query as it is to describe. For physical AI engineers who want to bolt intelligence onto telemetry pipelines without stitching together separate tools, this is a credible alternative to QuestDB's more hardware-conscious architecture.

TimescaleDB takes a different path. Built on top of PostgreSQL, it offers a familiar operational model: teams already running Postgres can add time-series capabilities without adopting a new database. QuestDB acknowledges this positioning, noting that TimescaleDB adds time series to a database you already run and know how to operate, and that at moderate volumes it can be a sensible choice. In QuestDB's benchmarks, tuned to specific hardware, TimescaleDB wins certain threshold scans and the top-N query, though QuestDB argues it is the stronger option where speed is mission critical and every sample counts. The distinction matters for physical AI: a robot fleet generating telemetry at high frequency cannot tolerate the downsampling and data loss that TimescaleDB's PostgreSQL foundation may introduce under extreme write loads.

Physical AI engineers weigh a familiar set of criteria. One analysis notes that QuestDB's trade-offs include a modest ecosystem and limited open-source clustering. InfluxDB 3 counters with a larger installed base, deeper cloud integration, and an AI-native feature set that QuestDB has yet to match. TimescaleDB counters with operational familiarity and the gravitational pull of the PostgreSQL ecosystem. Each engineer must answer whether the database sits on the critical path, where a lost data point corrupts a control loop or a telemetry window, or supports monitoring where occasional loss is acceptable. InfluxDB 3's move to Parquet storage and SQL compatibility narrows the technical gap, but the line between monitoring-grade and mission-grade time-series databases remains where this competitive battle will be decided.

New Query Primitives for Real-World Data

QuestDB's SQL dialect was built on a trading floor, where the cost of a missing tick is measured in dollars and milliseconds. That origin story matters now because the physical world, a robot arm coordinating six joints at 1 kHz, a rocket telemetry stream streaming thousands of sensor channels per second, imposes the same sub-millisecond, no-drop requirements that capital markets demanded a decade ago. The query primitives that satisfy those requirements are not the ones most engineers learned with InfluxDB or TimescaleDB. They are ASOF JOIN, HORIZON JOIN, and a novel array type that arrived with QuestDB 9.0, together forming a stack purpose-built for spatial-temporal workloads that traditional monitoring databases cannot express.

The most consequential primitive for physical systems is ASOF JOIN. It matches each row in a time-series table with the most recent row in another time-series table whose timestamp is at or before the left row's timestamp. In practice, this fuses a robot's pose estimate with the most recent command signal, or aligns a fleet's GPS readings with the last known obstacle-detection event. The join type is not new to relational databases, QuestDB also supports INNER, LEFT, RIGHT, FULL, CROSS, and LATERAL joins, but ASOF JOIN is optimized for the temporal asymmetry that characterizes physical data: events arrive out of order, and you need the latest known state at each timestamp, not an exact-match join that silently drops rows. QuestDB documents ASOF JOIN explicitly as a time-series extension, not a bolt-on feature.

HORIZON JOIN addresses a pattern drawn directly from financial markout analysis: measuring how a metric evolves at specific time offsets relative to an event. In robotics, this means answering questions like "how did the joint torque behave in the 50 milliseconds after the gripper engaged?" or "what is the trajectory deviation at each horizon offset following a correction command?" HORIZON JOIN supports joining against multiple right-hand-side tables in a single query, enabling aggregation of columns from several time-series sources against a common left-hand table and offset grid. This is the kind of multi-source temporal alignment that physical AI systems require and that conventional time-series databases either cannot express or require awkward self-joins and window-function workarounds to approximate.

The 9.0 release added a further primitive that blurs the line between database and ML framework: multi-dimensional arrays modeled on NumPy. These arrays store machine learning weights directly in the database, meaning an inference pipeline can read a model's parameters from the same system that ingests the telemetry stream, without a separate feature store or embedding database. The 9.0 release also introduced a binary line protocol for higher throughput and smaller message sizes, a direct response to latency complaints that early QuestDB users raised when writing data from Kafka. QuestDB describes the result as sub-millisecond analytics on billions of rows while keeping data in open Parquet format, a combination that matters for aerospace engineers who need both performance and the ability to move data off proprietary storage.

These primitives carry constraints. HORIZON JOIN cannot combine with other join types at the same query level, window functions are disallowed inside HORIZON JOIN queries, and the WHERE clause can only reference columns from the left-hand table, right-hand table columns and horizon pseudo-table columns like h.offset and h.timestamp are excluded. Engineers accustomed to PostgreSQL or even InfluxDB 3's newly added SQL support will need to restructure queries to work within these boundaries. QuestDB flags these limitations explicitly, and they represent a real architectural trade-off: the database optimizes for the temporal join patterns that matter most in high-frequency telemetry at the expense of general-purpose query flexibility.

The broader context makes these trade-offs worth evaluating. QuestDB's architecture was hardened under the extreme throughput demands of capital markets. That architecture now sits on the critical path in defense, energy, and robotics systems, where throughput is high and every sample counts. As QuestDB's stack combines Java, C++, and Rust, and its community of over 900 developers on Slack and 70 code contributors on GitHub expands, the question for physical AI engineers is no longer whether a time-series database can handle their workload, it is whether their current database can handle the join patterns that the physical world actually produces.

Why QuestDB Is Hiring in North America

QuestDB's expansion from capital markets into robotics, aerospace, and Physical AI is not just a product story, it is a hiring story. The company is actively recruiting pre-sales engineers for North America, posting roles on Y Combinator, Seedcamp, and BuiltIn as of early September 2026:

The listing, tagged "GTM / Sales Pioneer, North America / New York / Full-time," signals that QuestDB views the bridge between its trading-floor origins and the physical world as a revenue problem requiring human infrastructure, not just a technical one.

The job description reveals QuestDB's crossover strategy. QuestDB wants someone who can "position QuestDB against the incumbent time-series databases with precision: where we win, where we do not, and what a migration really involves." Most evaluations, the posting says, "are for new projects at firms that already run incumbent systems, so much of the work is making the case credible against what they know: the architecture, the numbers, and a plan their engineers believe they can execute." QuestDB is not simply riding a wave of organic demand into robotics and Physical AI. It is selling against entrenched alternatives, InfluxDB, TimescaleDB, and proprietary monitoring stacks, in domains where the buyer already has a database and a team that trusts it.

The pre-sales engineer's arsenal includes QuestDB's 17,000-star open-source repository, described as "the fastest-growing database in our category", its Best Trading Analytics Platform award at the TradingTech Summit Europe, noted as "the first non-legacy vendor to do so." QuestDB also runs at Airbus. The system handles 7,000 queries per second per instance with 99.9% uptime on Enterprise, QuestDB reported. The engineering culture's precision is visible in its hiring language: "If shaving 220µs off a query makes you excited, read on."

The organizational signal behind the North American push is distinct. QuestDB employs roughly 30 people, with local offices in London and New York and a remote-first default. The CEO is "on the ground in New York," and the pre-sales engineer "works closely with our CEO... and with the sales team on every deal." For a company of that size, having the CEO personally proximate to a single regional market is an unusual allocation of attention. It suggests North America is not a supporting act, it is where the physical-AI crossover plays out.

The candidate profile reinforces the thesis. QuestDB requires "3+ years" of experience, US citizenship or visa sponsorship, and what the posting calls "a precise communicator: explains trade-offs to a sceptical engineer, writes clearly, and says 'I will check' rather than guessing." QuestDB also says it "would rather lose an RFP than bolt on a closed-source dependency that traps the user." Both lines reveal the same tension at the heart of the crossover: physical-AI engineers evaluating database architectures are sophisticated, skeptical, and allergic to lock-in. The pre-sales role is not a sales role in the conventional sense, it is a technical credibility role, tasked with convincing engineers who build systems where every sensor reading matters that a database born on a trading floor can serve them better than the monitoring databases they already know.

QuestDB's expansion into those domains is the operational expression of a bet: that the capital-markets architecture, zero-loss, sub-millisecond, SQL-first, has a buyer outside the trading floor, and that buyer needs to be found, educated, and won one engineer at a time. On a trading floor, a dropped nanosecond is a lost trade. In a robot fleet, a dropped sensor reading is a missed collision window. QuestDB built its database for the former and is selling it for the latter, and it's hiring the people to make the case.

Working in frontier tech? Zero G Talent tracks the openings: see every open ASML role, browse frontier tech jobs, openings at Stripe, and the people building the field.