3 posts tagged with "benchmark"

We recently measured two implementations of the same application request over the MusicBrainz dataset:

Load the newest 100 recordings that have linked works, and load at most ten work relations for each recording.

The controlled SQLx test returned the same 100 recordings, 103 relation rows, 103 links, 103 link types, and Work-ID checksum through both paths. One took 5,871.169 milliseconds. The other took 2.469 milliseconds—a 2,378× difference inside SQLx itself.

TeaQL Rust previously completed the corresponding typed graph workload in 2.864 milliseconds. That does not mean TeaQL has a PostgreSQL driver 2,000× faster than SQLx. The difference was the amount of work requested from the database. The expert SQLx control proves it.

TeaQL does more during a query than map database rows into Rust structs.

It preserves loaded, null, and not-loaded state. It builds an identity-consistent object graph. It carries query purpose and diagnostic comments. The same runtime also supports checker/fix behavior, mutation ledgers, audit boundaries, and cross-data-source relations.

That raises a fair question: what does this additional runtime model cost on a real relational graph?

We tested a retained TeaQL Rust build against Diesel and SeaORM using a PostgreSQL copy of the public MusicBrainz database. The result is more useful than a simple winner: across three relationship shapes, TeaQL consistently landed between Diesel and SeaORM—and came within 3.4% of Diesel on one five-query graph.

A dynamic order page sounds ordinary: search, paginate, show status cards, and preview a few products. The interesting part begins when we ask what a production-grade implementation must actually contain—and count all of it.

We built the same read model with TeaQL Rust and conventional Rust plus SQLite. The first comparison was wrong in three important ways. Correcting those errors made the result more useful than the original benchmark.