Equal answers. Not yet equal speed.
Five TPC-H queries, the same generated data, answers compared decimal for decimal. UltraFabric's columnar collections are 11–46× slower than DuckDB on one thread on a shared development host. Three weeks earlier it was 137–1 408×.
The table from the report
Source: the TPC-H columnar report of 22 October 2026, commit a69b309, median of three including planning. Host: shared development host, 3 CPUs / 6 GB; indicative, not a production promise. Data: TPC-H SF 0.1, lineitem 600 572 rows.
TPC-H SF 0.1, seconds
Row storage, columnar collections, DuckDB 1.1.3 one thread
| Query | Row storage | Columnar | Columnar gain | DuckDB 1 thread | Columnar vs DuckDB | Answers |
|---|---|---|---|---|---|---|
| Q1 | 0.869 | 0.308 | 2.8× | 0.0128 | 24× | equal |
| Q3 | 0.71 | 0.166 | 4.3× | 0.0085 | 20× | equal |
| Q5 | 0.896 | 0.363 | 2.5× | 0.0078 | 46× | equal |
| Q6 | 0.535 | 0.074 | 7.3× | 0.002 | 36× | equal |
| Q10 | 0.771 | 0.245 | 3.1× | 0.0229 | 11× | equal |
How the gap closed, 21–22 Oct
Seconds per query across four executor and storage phases
- 21 Oct, first run: 137–1 408× DuckDB; the phase gate (3×) recorded as missed.
- Projected scans and typed decimals: 1.9–3.5× faster.
- Vectorised expressions and batch aggregation: 3.7–6.1× faster than the first run.
- 22 Oct, columnar collections: 11–46× DuckDB. The analytics page lists what remains.
Where DuckDB is ahead
A comparison that hides the other side's strengths is advertising. These are the points a buyer would find anyway.
11–46× faster on one thread
On every one of the five queries. The gap is the executor: per-row validity vectors, row-at-a-time hash joins and group keys, no SIMD, a single thread. Reading two columns of lineitem's row groups takes about 15 ms, so storage is no longer the limit.
Parallel execution
DuckDB uses every core; UltraFabric's executor is single-threaded today. The 21 October report records DuckDB three-thread times as well, and they are lower still on most queries.
Full SQL
Subqueries, WITH, window functions, DISTINCT and HAVING all fail on UltraFabric with SQLSTATE 0A000 today. DuckDB runs the whole TPC-H suite; UltraFabric runs five hand-selected queries.
Zero setup
DuckDB is an in-process library. UltraFabric is a node and a gateway with token login, which is the point of it, and also more to run.
What DuckDB does not offer
Built and tested today, not planned.
Tenant isolation verified on every plan
Each query runs over a security chain the verifier checked for the requester's tenant and clearance. 994 405 paired-database checks in the ten-million-plan campaign found no interference.
BuiltRow and columnar under one verifier
The same table syntax, the same SQL subset and the same check, whether a table is stored as rows for records or as column chunks for facts.
BuiltDurable, transactional writes
A write-ahead log with group commit and snapshot-isolation transactions sit under the analytic tables; an INSERT is on disk before it is acknowledged.
BuiltA network service over the PostgreSQL protocol
psql and drivers connect with a token verified at the gateway and again at the node.
BuiltStatus today
Not compatible, and not trying to be
UltraFabric speaks the PostgreSQL protocol, not DuckDB's API, and runs a small SQL subset. In the benchmark tool, DuckDB 1.1.3 generates the data with its dbgen and supplies the reference answers: decimals must match exactly and averages within a relative 1e-9. The five queries are hand-written plans in UltraFabric's plan language, verified, optimised and re-verified exactly as the node does, then executed; DuckDB's time is per query excluding process start, median of three.
Why compare with DuckDB's single-thread time?
UltraFabric's executor runs on one thread today, so the one-thread figure is the fair comparison. The 21 October report also records DuckDB on three threads; the gap to that figure is larger.
Did the 3× gate pass?
No. The phase gate asked for the TPC-H subset within 3× of DuckDB on one node. It is missed by 11–46× today, down from 137–1 408×. The decision record keeps the goal and re-measures at each step.
Is DuckDB used inside UltraFabric?
Only in the benchmark tool: DuckDB generates the TPC-H data (dbgen) and provides the answers every UltraFabric result is compared with. It is not part of the database.
Run the same benchmark yourself.
Every report names its commit, tool invocation and raw result file. Early-access teams receive the scripts with the build.