We run one workload on every Pixeltable release, on one machine, and log what changed the numbers and why.
16 releases, 0.7.0 to 0.7.15, on one Apple M4 Pro. Recorded October 8, 2026. Dev log · Releases · Method
One-row insert
CPU time per insert into a table with two computed columns, median of 300
0.7.15 2.45 ms
100-row batch insert
Rows per second over 20 batches of 100
0.7.15 18,222 rows/s
10,000-row backfill
CPU time to add the same two computed columns to a table of 10,000 rows
0.7.15 0.41 s
| Step | 0.7.0 | 0.7.15 | Change |
|---|---|---|---|
| One-row insertCPU time per insert into a table with two computed columns, median of 300 | 2.99 ms | 2.45 ms | 1.2x faster |
| 100-row batch insertRows per second over 20 batches of 100 | 11,826 rows/s | 18,222 rows/s | 1.5x faster |
| 10,000-row backfillCPU time to add the same two computed columns to a table of 10,000 rows | 0.90 s | 0.41 s | 2.2x faster |
| Point queryCPU time per filtered select of one row from 300, median of 300 | 1.77 ms | 1.89 ms | no clear change |
| Table.compute() on one rowCPU time per call, median of 300 | 1.02 ms | 0.95 ms | no clear change |
| import pixeltableWall time for a fresh interpreter | 3.05 s | 3.19 s | no clear change |
| SQL statements per insertCounted from SQLAlchemy cursor events | 11 | 11 | same |
Each value is the best of 5 runs. Compare releases with each other, not with a different machine. How we measure
A one-row insert into a table with two computed columns sends 11 SQL statements in every release from 0.7.0 to 0.7.15.
Here the database is an embedded Postgres on the same machine, so a whole insert takes about 2.45 ms of CPU. On a hosted database each statement is a network round trip, which is why the same insert takes tens of milliseconds on the cloud comparison.
From 0.7.1 to 0.7.2, the 10,000-row backfill went from 0.93 s to 0.41 s of CPU, 100-row batches from 11,605 rows/s to 19,059 rows/s, and a one-row insert from 2.96 ms to 2.37 ms. No later release has moved them since.
0.7.2 stopped creating a B-tree index on every column by default; Table.add_btree_index() adds one where a query needs it. To check that this change accounts for the whole step, we added the indexes back to 0.7.14: it measured 0.90 to 0.95 s for the backfill and about 11,400 rows/s, which are 0.7.1's numbers.
Our point query filters a 300-row table, where an index makes no measurable difference. On a large table, a filter on a column with no index scans the table.
from __future__ import annotations #1666bytes and ndarrays out of band during insertion #1609sentence_transformers >= 5.4 #1620pxt service example writes #1632from __future__ import annotations #1556TableModelMeta to work on Python 3.14+ without from __future__ import annotations #1564