The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Was TeaQL really 2,000× faster than SQLx? Not in a controlled, like-for-like comparison. The reported 2,378× gap was between two SQLx query plans: one ranked relations across roughly 2.7 million rows before narrowing to the requested recordings, while the other selected the 100 recording roots first and ranked only their relations. TeaQL’s separate 2.864 ms run is useful context, but it is not part of that ratio.
What the 2,378× comparison measured
The request was to fetch the newest 100 recordings that have linked works, along with up to ten work relations per recording. In the reported MusicBrainz fixture, both controlled SQLx paths returned 100 recordings, 103 relation rows, 103 links, 103 link types, and the same Work-ID checksum. The key difference was the order and scope of database work.
As an Amazon Associate I earn from qualifying purchases.
| Reported path | Query shape | PostgreSQL median | What the figure compares |
|---|---|---|---|
| Natural single-statement SQLx | Ranks relations across the fixture with a window function, then selects roots and keeps up to ten relations per root. | 5,871.169 ms | One controlled SQLx path, as reported in the TeaQL article dated September 30, 2026. |
| Expert SQLx control | Selects the 100 root IDs first, then ranks only relations whose parent is in that selected set. | 2.469 ms | The other controlled SQLx path, measured on the same reported fixture. |
The article reports the second path as 2,378× faster than the first. Those are author-reported measurements, not independently reproduced results. The reported controlled setup used one initialized pool connection, three warmups, and ten sequential measurements. The article also reports an earlier raw JDBC result of 5,579.224 ms and an earlier DuckDB result of 808.158 ms for the global-ranking shape; those are separate reported results, not part of the SQLx ratio.
Why the obvious query took so much longer
A window function that ranks every relation must process rows that cannot appear in the requested page. The article says the global-ranking SQLx query ranked about 2.7 million relation rows, then applied the selected-root bound. For this request, most of that ranking work could not affect the final 100 recordings or their limited relation sets.
#1 Best Overall
The root-first plan reverses that scope: it identifies the page of recordings, then ranks child relations only for those selected roots. In this fixture, that bound sharply reduced the work PostgreSQL needed to do while preserving the reported output cardinalities and checksum. The headline is therefore best understood as a query-planning result—not as evidence that one Rust library’s database driver is thousands of times faster than another’s.
Where TeaQL fits—and where it does not
The article reports a separate TeaQL Rust typed-graph run at 2.864 ms. That timing is context, not part of the controlled 2,378× SQLx comparison. TeaQL hydrated entities and assembled an identity graph, while the SQLx control decoded aggregate tuples, so the two numbers also cover different result-handling work.
TeaQL’s project describes a model-driven runtime with typed models and queries, SQL compilation, relation enhancement, graph writes, and PostgreSQL, MySQL, and SQLite providers (TeaQL project). Its approach expresses a bounded object graph—select roots, load a limited number of ordered relations for each, and hydrate referenced objects—so its runtime can avoid ranking unrelated relations in this workload. SQLx describes itself as an asynchronous Rust SQL toolkit with optional compile-time query checking and PostgreSQL, MySQL, MariaDB, and SQLite support (SQLx project).
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Neither description establishes a universal performance advantage. TeaQL offers a higher-level model and graph abstraction; SQLx is a reasonable fit when explicit SQL is the intended abstraction. The useful comparison is whether each approach expresses the same bounds, performs the same database work, and includes the same decoding or hydration in its measured time.
What this result does—and does not—prove
- It does show that the two reported SQLx query shapes had a large performance difference on this fixture, despite matching output counts and checksum.
- It does not show that SQLx itself is slow. The expert SQLx plan was the fast path in the controlled comparison.
- It does not show that every window-function query is inefficient, or that multiple queries are always better than one statement.
- It does not establish that TeaQL is intrinsically faster than SQLx on PostgreSQL; its reported timing came from a separate run with different result handling.
- It cannot be generalized automatically to other hardware, fixtures, indexes, databases, or application workloads.
How to evaluate the same pattern in your application
When a query loads a page of parent records and a bounded set of related rows, inspect whether the database applies the parent-page limit before ranking or aggregating children. Then compare plans that produce the same result, rather than comparing library names or isolated timings.
- Verify output cardinality and a stable correctness check, such as the reported checksum, across candidate plans.
- Record when root and child limits are applied, how many rows are scanned or ranked, and the indexes and fixture scale used.
- Compare the number of database round trips and whether timings include decoding, entity hydration, or graph assembly.
- Keep the measurement protocol visible: warmups, connection setup, repetitions, and the statistic reported.
- Before replacing a model-driven query with hand-written SQL, check that authorization, tenant scope, version policy, and tracing semantics remain intact. The reported benchmark raises these as design considerations; it does not provide a comparative security test.
The practical takeaway
“An expert can—and in this benchmark did—write the fast SQLx plan,” TeaQL article author Philip Z wrote. The dramatic number comes from comparing a global-ranking plan with a root-first bounded plan on one reported fixture. The transferable lesson is to push the page’s real bounds into the work that follows them—and to compare equivalent work, not just the labels on the libraries.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
