The same input and the same kernels, in neo's C++ and in DuckDB 1.5.6. Across 24 measurements neo finished 10.6× faster in the middle and 112× at most; DuckDB was not quicker on any.
01 · The race
One kernel at a time
Each piece of work below has its own race, what it measures, what neo is held to, how DuckDB does it and every number taken for it. In a race both ships run for the same stretch: DuckDB completes the work once, and neo completes it as many times as the measured ratio says, turning around at each end.
Read a 46 MB CSV of a million rows and six columns into a table: split the bytes into fields, parse the amount column into numbers, and dictionary-encode the region column. Each engine's typed read, best of two, with the first read of a fresh process kept separately.
What neo is held to
The same table the app loads, with the amount column typed and the region column encoded at load, so that no kernel after it touches text. Before a time is taken every engine prints its table as one number and its checks, and the line under the table says whether they agreed.
How DuckDB does it
read_csv into a new table inside DuckDB, with DuckDB choosing the column types.
DuckDB, this kernel · neon-cpp/bench/lang/python/yardstick.py
res["load_first_ms"], res["load_ms"] = load_twice(lambda: con.execute("CREATE OR REPLACE TABLE t AS SELECT * FROM read_csv(?, header=true)", [args.csv]))
neo's side is confidential. What it is held to is above; why it is kept is under 03.
Every number taken for it
measurement
neo
DuckDB
× neo
time, runs in a row, msThe typed read, best of two, with the first read of a fresh process kept separately.
2.77
51.8
18.7×
energy, runs in a row, mJMillijoules a run, in the same run as the time: the energy over the timed runs and as many more as fill 200 ms, divided by the runs, less the draw at rest. A mean, where the time is a best.
Count the rows whose amount is over 500: a million comparisons on a typed column, the answer one integer. Each library's count is written the way its users write it.
What neo is held to
The count every other engine prints, under the JavaScript node's rule that NaN never matches. What comes out is a selection the next kernel reads from, not a copy of the rows.
How DuckDB does it
A plain SELECT count(*) with the predicate in its WHERE clause, and the one row fetched.
DuckDB, this kernel · neon-cpp/bench/lang/python/yardstick.py
timed("filter", lambda: con.execute("SELECT count(*) FROM t WHERE amount > 500").fetchone())
neo's side is confidential. What it is held to is above; why it is kept is under 03.
Every number taken for it
measurement
neo
DuckDB
× neo
time, runs in a row, msBest of three, runs in a row: every thread awake and the cores at speed.
0.018
0.602
33.5×
energy, runs in a row, mJMillijoules a run, in the same run as the time: the energy over the timed runs and as many more as fill 200 ms, divided by the runs, less the draw at rest. A mean, where the time is a best.
1.08
14.8
13.7×
time, one run from rest, msThe call made once after 50 ms of nothing, mean of ten: what a click finds.
0.782
1.32
1.69×
energy, one run from rest, mJThe same single call from rest, in millijoules. From rest a run costs less than in a row where the work is large, and more where it is tiny, because the threads have to be woken for it.
Keep the rows whose amount is over 500 and build a new table of them, about half the file, every column copied.
What neo is held to
The same rows every other engine keeps, every column copied, checked by the same line.
How DuckDB does it
CREATE TABLE AS with the predicate: SQL's form of a materialised result, so DuckDB writes the rows into a table of its own.
DuckDB, this kernel · neon-cpp/bench/lang/python/yardstick.py
timed("filter_mat", lambda: con.execute("CREATE OR REPLACE TABLE f AS SELECT * FROM t WHERE amount > 500"))
neo's side is confidential. What it is held to is above; why it is kept is under 03.
Every number taken for it
measurement
neo
DuckDB
× neo
time, runs in a row, msBest of three, runs in a row: every thread awake and the cores at speed.
0.380
40.3
106×
energy, runs in a row, mJMillijoules a run, in the same run as the time: the energy over the timed runs and as many more as fill 200 ms, divided by the runs, less the draw at rest. A mean, where the time is a best.
Produce the stable ascending order of the amount column as a permutation of row indices, without moving any other column. SQL engines have no such form, so DuckDB and Spark sit this one out.
What neo is held to
A stable ascending order under the JavaScript rule that NaN sorts first and ties keep their place. The first sorted values are printed and compared with every other engine's.
How DuckDB does it
SQL has no form for an ordering apart from the table it orders, so nothing is timed here and the cell is left blank. The sorted table, in the segment after this one, is the form DuckDB has.
DuckDB, this kernel · neon-cpp/bench/lang/python/yardstick.py
res["sort_perm_ms"] = None # SQL has no permutation; the sorted table is the only form
neo's side is confidential. What it is held to is above; why it is kept is under 03.
Every number taken for it
measurement
neo
DuckDB
× neo
time, runs in a row, msBest of three, runs in a row: every thread awake and the cores at speed.
1.03
—
—
energy, runs in a row, mJMillijoules a run, in the same run as the time: the energy over the timed runs and as many more as fill 200 ms, divided by the runs, less the draw at rest. A mean, where the time is a best.
64.5
—
—
time, one run from rest, msThe call made once after 50 ms of nothing, mean of ten: what a click finds.
2.73
—
—
energy, one run from rest, mJThe same single call from rest, in millijoules. From rest a run costs less than in a row where the work is large, and more where it is tiny, because the threads have to be woken for it.
Sort by amount and build the whole sorted table, every column reordered.
What neo is held to
The whole table in that order, every column, with the same first values as every other engine.
How DuckDB does it
CREATE TABLE AS with ORDER BY amount: the sorted table written into DuckDB's own storage.
DuckDB, this kernel · neon-cpp/bench/lang/python/yardstick.py
timed("sort_mat", lambda: con.execute("CREATE OR REPLACE TABLE s AS SELECT * FROM t ORDER BY amount"))
neo's side is confidential. What it is held to is above; why it is kept is under 03.
Every number taken for it
measurement
neo
DuckDB
× neo
time, runs in a row, msBest of three, runs in a row: every thread awake and the cores at speed.
2.72
23.4
8.62×
energy, runs in a row, mJMillijoules a run, in the same run as the time: the energy over the timed runs and as many more as fill 200 ms, divided by the runs, less the draw at rest. A mean, where the time is a best.
Total the amount column for each of five regions: a grouped sum, the kernel every dashboard runs.
What neo is held to
The JavaScript loop's result to the bit. A floating-point sum depends on the order it is taken in, and neo is held to the row order's answer whatever it does to get there.
How DuckDB does it
A GROUP BY on region with sum(amount), and every row of the answer fetched.
DuckDB, this kernel · neon-cpp/bench/lang/python/yardstick.py
timed("agg", lambda: con.execute("SELECT region, sum(amount) FROM t GROUP BY region").fetchall())
neo's side is confidential. What it is held to is above; why it is kept is under 03.
Every number taken for it
measurement
neo
DuckDB
× neo
time, runs in a row, msBest of three, runs in a row: every thread awake and the cores at speed.
0.020
2.24
112×
energy, runs in a row, mJMillijoules a run, in the same run as the time: the energy over the timed runs and as many more as fill 200 ms, divided by the runs, less the draw at rest. A mean, where the time is a best.
1.55
72.3
46.7×
time, one run from rest, msThe call made once after 50 ms of nothing, mean of ten: what a click finds.
0.758
5.68
7.49×
energy, one run from rest, mJThe same single call from rest, in millijoules. From rest a run costs less than in a row where the work is large, and more where it is tiny, because the threads have to be woken for it.
9.11
38.0
4.17×
01.7 · public data · a file this project did not make
Read worldcitiespop from its path to a table in memory: 3,173,958 rows by 7 columns, 151 MB of place names, the file the CSV tools benchmark on. Every engine in a fresh process each round, the file in the OS cache, each engine's start-up done before the clock; warm is the median of the loads after the first. neo's table is text, with no types, no nulls and no UTF-8 check, so the rows as text are the like-for-like ones.
What neo is held to
The same loader the app uses, on a file this project did not make, checked column by column and row by row against DuckDB's reading of it before any time is taken.
How DuckDB does it
read_csv with all_varchar into a new table, so every column is text. One query is run first, untimed, so that the binding's own set-up is not counted as loading.
DuckDB reading the public files · neon-cpp/bench/lang/python/standards.py:40
def load_duckdb(path, mode, loads, opt=None):
import duckdb
con = duckdb.connect()
con.execute("SELECT 42").fetchall() # untimed: what the binding sets up on its first query (it imports pandas) is not CSV loading
opts = ", all_varchar=true" if mode == "text" else ""
out, rows, cols = [], 0, 0
for _ in range(loads):
con.execute("DROP TABLE IF EXISTS t")
t0 = time.perf_counter()
con.execute(f"CREATE TABLE t AS SELECT * FROM read_csv(?, header=true{opts})", [path])
out.append(ms_since(t0))
rows = con.execute("SELECT count(*) FROM t").fetchone()[0]
cols = len(con.execute("SELECT * FROM t LIMIT 0").description)
threads = con.execute("SELECT current_setting('threads')").fetchone()[0]
return duckdb.__version__, out, rows, cols, int(threads)
neo's side is confidential. What it is held to is above; why it is kept is under 03.
Every number taken for it
measurement
neo
DuckDB
× neo
first load, as text, msThe median first load: a fresh process each round, the file in the operating system's cache, the engine's own start-up done before the clock.
23.8
252
10.6×
loads after the first, as text, msThe median of the loads after the first, in the same process.
11.4
91.8
8.08×
01.8 · public data · a file this project did not make
Read NYC taxi · 1M from its path to a table in memory: 1,000,000 rows by 51 columns, 425 MB of trips. Every engine in a fresh process each round, the file in the OS cache, each engine's start-up done before the clock; warm is the median of the loads after the first. neo's table is text, with no types, no nulls and no UTF-8 check, so the rows as text are the like-for-like ones.
What neo is held to
The same loader the app uses, on a file this project did not make, checked column by column and row by row against DuckDB's reading of it before any time is taken.
How DuckDB does it
read_csv with all_varchar into a new table, so every column is text. One query is run first, untimed, so that the binding's own set-up is not counted as loading. The reader is the one shown under the first public file.
neo's side is confidential. What it is held to is above; why it is kept is under 03.
Every number taken for it
measurement
neo
DuckDB
× neo
first load, as text, msThe median first load: a fresh process each round, the file in the operating system's cache, the engine's own start-up done before the clock.
72.9
827
11.3×
loads after the first, as text, msThe median of the loads after the first, in the same process.
52.9
661
12.5×
01.9 · public data · a file this project did not make
Read NYC taxi · 10M from its path to a table in memory: 10,000,000 rows by 51 columns, 4.3 GB of trips. Every engine in a fresh process each round, the file in the OS cache, each engine's start-up done before the clock; warm is the median of the loads after the first. neo's table is text, with no types, no nulls and no UTF-8 check, so the rows as text are the like-for-like ones.
What neo is held to
The same loader the app uses, on a file this project did not make, checked column by column and row by row against DuckDB's reading of it before any time is taken.
How DuckDB does it
read_csv with all_varchar into a new table, so every column is text. One query is run first, untimed, so that the binding's own set-up is not counted as loading. The reader is the one shown under the first public file.
neo's side is confidential. What it is held to is above; why it is kept is under 03.
Every number taken for it
measurement
neo
DuckDB
× neo
first load, as text, msThe median first load: a fresh process each round, the file in the operating system's cache, the engine's own start-up done before the clock.
448
2,752
6.14×
loads after the first, as text, msThe median of the loads after the first, in the same process.
418
2,539
6.07×
01.10 · public data · a file this project did not make
Read ClickBench · 1M from its path to a table in memory: 1,000,000 rows by 105 columns, 842 MB of web hits. Every engine in a fresh process each round, the file in the OS cache, each engine's start-up done before the clock; warm is the median of the loads after the first. neo's table is text, with no types, no nulls and no UTF-8 check, so the rows as text are the like-for-like ones.
What neo is held to
The same loader the app uses, on a file this project did not make, checked column by column and row by row against DuckDB's reading of it before any time is taken.
How DuckDB does it
read_csv with all_varchar into a new table, so every column is text. One query is run first, untimed, so that the binding's own set-up is not counted as loading. The reader is the one shown under the first public file.
neo's side is confidential. What it is held to is above; why it is kept is under 03.
Every number taken for it
measurement
neo
DuckDB
× neo
first load, as text, msThe median first load: a fresh process each round, the file in the operating system's cache, the engine's own start-up done before the clock.
126
1,647
13.0×
loads after the first, as text, msThe median of the loads after the first, in the same process.
96.0
1,438
15.0×
01.11 · public data · a file this project did not make
Read ClickBench · 10M from its path to a table in memory: 10,000,000 rows by 105 columns, 8.1 GB of web hits. Every engine in a fresh process each round, the file in the OS cache, each engine's start-up done before the clock; warm is the median of the loads after the first. neo's table is text, with no types, no nulls and no UTF-8 check, so the rows as text are the like-for-like ones.
What neo is held to
The same loader the app uses, on a file this project did not make, checked column by column and row by row against DuckDB's reading of it before any time is taken.
How DuckDB does it
read_csv with all_varchar into a new table, so every column is text. One query is run first, untimed, so that the binding's own set-up is not counted as loading. The reader is the one shown under the first public file.
neo's side is confidential. What it is held to is above; why it is kept is under 03.
Every number taken for it
measurement
neo
DuckDB
× neo
first load, as text, msThe median first load: a fresh process each round, the file in the operating system's cache, the engine's own start-up done before the clock.
1,053
4,626
4.39×
loads after the first, as text, msThe median of the loads after the first, in the same process.
1,056
4,682
4.43×
02 · Every number
Against the libraries people reach for first
1,000,000 rows · ms, lower is better · 2026-10-11 21:23
kernel
neo
DuckDB
× neo
load the CSV (parse + type)
2.77
51.8
18.7×
filter amount > 500, count
0.018
0.602
33.5×
filter into a new table
0.380
40.3
106×
sort into a new table
2.72
23.4
8.62×
sum(amount) by region
0.020
2.24
112×
filter, count: one run from rest
0.782
1.32
1.69×
sum by region: one run from rest
0.758
5.68
7.49×
The same CSV and the same six kernels in neo's engine and in the libraries people reach for first, each written the way its users write it (Polars 2.0.0, DuckDB 1.5.6, pandas 3.0.6, Spark 4.2.0). Milliseconds, best of three; the chip is how many times neo's time a library took. The last three rows are one run from rest: the call made once after 50 ms of nothing, mean of ten, neo's pool told to rest after it as the editor tells it. That is what a click finds; the rows above are runs in a row, every thread awake and the cores at speed.
The same run, in energy
1,000,000 rows · mJ, lower is better · 2026-10-11 21:23
kernel
neo
DuckDB
× neo
load the CSV (parse + type)
172
1,421
8.26×
filter amount > 500, count
1.08
14.8
13.7×
filter into a new table
21.6
568
26.3×
sort into a new table
144
900
6.26×
sum(amount) by region
1.55
72.3
46.7×
filter, count: one run from rest
8.72
9.40
1.08×
sum by region: one run from rest
9.11
38.0
4.17×
The same CSV and the same six kernels as the times, in the same run (Polars 2.0.0, DuckDB 1.5.6, pandas 3.0.6, Spark 4.2.0). Millijoules a run. What macOS billed each engine's process, and for Spark its JVM, for the processor cores it ran on: not the memory, the disk or the screen, and not the machine at rest. A kernel's figure is the energy over its timed runs, and as many more as fill 200 ms, divided by the runs, less what the process draws at rest for as long: a mean, where the time is a best. neo's is of the variant whose time is the number on the Speed side. Each benchmark reads the counter itself; scripts/bench_libraries.sh also reads it from outside the process (neon_energy) and RESULTS.md has both totals. The chip is how many times neo's energy a library used. The last three rows are one run from rest: the call made once after 50 ms of nothing, mean of ten, neo's pool told to rest after it as the editor tells it. That is what a click finds; the rows above are runs in a row, every thread awake and the cores at speed. From rest a run costs less energy than in a row where the work is large (the cores are not at their top voltage) and more where it is tiny (the threads have to be woken for it).
Public data, from a path to a table
loads after the first, as text · ms, lower is better · 2026-10-11 16:43
kernel
neo
DuckDB
× neo
worldcitiespop · first load, as text
23.8
252
10.6×
worldcitiespop · loads after the first, as text
11.4
91.8
8.08×
NYC taxi · 1M · first load, as text
72.9
827
11.3×
NYC taxi · 1M · loads after the first, as text
52.9
661
12.5×
NYC taxi · 10M · first load, as text
448
2,752
6.14×
NYC taxi · 10M · loads after the first, as text
418
2,539
6.07×
ClickBench · 1M · first load, as text
126
1,647
13.0×
ClickBench · 1M · loads after the first, as text
96.0
1,438
15.0×
ClickBench · 10M · first load, as text
1,053
4,626
4.39×
ClickBench · 10M · loads after the first, as text
1,056
4,682
4.43×
Public CSVs, not ours, from a path to a table in memory, in neo and in engines this project did not write (Arrow 25.0.1, Polars 2.0.0, DuckDB 1.5.6, pandas 3.0.6). Milliseconds. worldcitiespop.csv is the file as xsv, qsv, xan and zsv benchmark it; the taxi and ClickBench files are the first records of the files those benchmarks publish, byte for byte, under a header line made from the benchmark's own schema (scripts/fetch_standards.sh; every source and SHA-256 is in bench/results/standards/manifest.jsonl). Every engine runs in a fresh process each round, in an order shuffled each round: the first row is the median first load, the second the median of the loads after it. The file is in the operating system's cache throughout, and each engine's own start-up is done before its first load, so these are the readers and nothing else. neo goes through the loader the app uses. Its table is text and only text: no types, no nulls (an empty field is an empty string), no check that the bytes are UTF-8, every field trimmed and a line end inside quotes made \n, as the app it replaces did; the others asked for text check UTF-8 and keep nulls. So the first two rows are the like-for-like ones; in the last two the others also infer types, which neo's loader does not do, and neo's numbers there are its text load again. Before any time is taken neo's table is compared with DuckDB's reading of the file, and each card says what came of it. pandas is run with its pyarrow engine. Threads are each engine's default: 18 here for the others; neo 16, and 18 from 256 MB of input, counts that were chosen on this machine. A dash is an engine that did not read the file.
03 · Both sides
DuckDB's side, in full
DuckDB is an in-process analytical SQL database: columnar, vectorised, run from inside Python with no server to start. Its kernels are written the way its users write them. Each kernel's lines are beside its race above; this is the whole block they come from, with the checks it prints.
duckdb, as its users write it: the six kernels · neon-cpp/bench/lang/python/yardstick.py:237
elif args.lib == "duckdb":
t0 = now()
import duckdb
res["version"] = duckdb.__version__
con = duckdb.connect()
con.execute(f"PRAGMA threads={args.threads}")
res["startup_ms"] = (now() - t0) * 1000
res["load_first_ms"], res["load_ms"] = load_twice(lambda: con.execute("CREATE OR REPLACE TABLE t AS SELECT * FROM read_csv(?, header=true)", [args.csv]))
res["rows"] = con.execute("SELECT count(*) FROM t").fetchone()[0]
timed("filter", lambda: con.execute("SELECT count(*) FROM t WHERE amount > 500").fetchone())
timed("filter_mat", lambda: con.execute("CREATE OR REPLACE TABLE f AS SELECT * FROM t WHERE amount > 500"))
res["sort_perm_ms"] = None # SQL has no permutation; the sorted table is the only form
timed("sort_mat", lambda: con.execute("CREATE OR REPLACE TABLE s AS SELECT * FROM t ORDER BY amount"))
timed("agg", lambda: con.execute("SELECT region, sum(amount) FROM t GROUP BY region").fetchall())
checks["filter_count"] = con.execute("SELECT count(*) FROM t WHERE amount > 500").fetchone()[0]
checks["first_sorted"] = [float(r[0]) for r in con.execute("SELECT amount FROM t ORDER BY amount LIMIT 3").fetchall()]
checks["sums"] = {r[0]: float(r[1]) for r in con.execute("SELECT region, sum(amount) FROM t GROUP BY region").fetchall()}
neo's side: confidential
neo's kernels, the ports written in-house to beat them, and the techniques behind both stay with the engine. Nothing about how the numbers were made is withheld: the method, the checks every engine had to pass, every number and every place neo is behind are on this page. The engine itself we keep confidential, because we don't want it getting into the wrong hands. The binaries run on request and reproduce every number here.
04 · Diligence
What both sides were held to
Same input, same answer. Every engine reads the same file and prints the same checks line: the filter count, the first sorted values, the group sums. A number enters the ledger only when the checks agree with the C++.
Timed the same way. A kernel is the best of three in one process; a load is the engine's typed read, best of two, with the first read of a fresh process kept separately. Engines that need a warm-up get it before the clock.
Energy is what the machine billed. Millijoules a run, read from the hardware counters for each engine's whole process tree, with the draw at rest subtracted for the seconds of the window.
The machine is named, and so is its load. Apple M5 Max, 18 cores, 26.4.1. The load average before each run is in the ledger, and a study taken on a shared machine says so beside its numbers.
Where DuckDB wins, it is shown winning. None of the 24 measurements on this page, and that is also a measurement.
The caveat on this comparison. SQL has no sort permutation, so that row is blank for DuckDB. Its filter and sort are timed as CREATE TABLE, the honest equivalent of a materialised table, and its count is a plain SELECT. DuckDB also serves as the oracle: neo's reading of every public file is compared with DuckDB's before any time is taken.
What is kept back. neo's kernels, the in-house ports and the techniques behind them: we don't want them getting into the wrong hands. The binaries run on request.
Scripts: scripts/bench_libraries.sh · scripts/bench_standards.sh · measured 2026-10-11 · the numbers on this page come from the same ledger as the app's own Evals page, written by neon-cpp/scripts/results_md.py.