Stoolap Promises 138x Speed Over SQLite. It Delivers 6x.

I've watched enough product launches to know that benchmark claims and reality occupy different zip codes. So when a new Rust-based database called Stoolap started circulating with claims of being 138 times faster than SQLite, my first thought wasn't "wow." It was "what are they measuring?"

The folks at Better Stack actually ran the numbers, and the results are more interesting than the marketing copy—because they reveal exactly what happens when you take breathless performance claims and subject them to actual use cases.

The Setup: OLAP vs. OLTP

First, the fair framing: Stoolap and SQLite aren't really competitors. They're designed for different jobs. SQLite is OLTP—online transaction processing—optimized for the kind of work most applications do most of the time. Insert this row, update that field, fetch these records. The boring, critical stuff that keeps your app running.

Stoolap is OLAP—online analytical processing. It's built for the queries that make SQLite sweat: aggregations across millions of rows, complex analytical operations, the kind of work where you're asking "what patterns exist in this data" rather than "give me record 47."

As the Better Stack team explains it: "Think of it as having the portability of a SQLite file but with the raw analytical power of something like a duck DB or big query."

That's the pitch. Embed an analytical database in your Node.js app, skip the serialization overhead of talking to a separate database process, and watch your complex queries fly.

The Architecture: Actually Interesting

Here's where Stoolap does something genuinely clever. Most database bindings for Node.js are bridges—your JavaScript sends data over in JSON or some other format, the database does its thing in another process, then sends results back the same way. That serialization overhead is measurable and real.

Stoolap uses NAPI-RS to compile the Rust database engine directly into your Node process. No bridge, no serialization. As they describe it: "When you send a query, NodeJS and Rust are essentially sharing the same memory space."

The database also uses multi-version concurrency control (MVCC) instead of SQLite's single-writer-locks-everything approach, parallel execution via the Rayon library to utilize multiple CPU cores, and a cost-based optimizer that analyzes query paths before executing.

These aren't marketing buzzwords—they're legitimate architectural choices that should, in theory, make certain workloads significantly faster. The question is: how much faster, and for which workloads?

The Reality: 138x Becomes 6x

Better Stack set up a straightforward test: 10,000 rows of random sales data, then a COUNT DISTINCT query—supposedly one of Stoolap's strongest use cases. The result? Stoolap was four times faster. Not 138 times. Four.

Okay, maybe 10,000 rows isn't enough to show the difference. Scale it up to a million rows. The gap widens to... six times faster. Still nowhere near 138x.

A second test using DISTINCT with ORDER BY showed Stoolap running just 1 to 1.5 times faster than SQLite. At that margin, you're in "maybe worth it if you have a specific problem" territory, not "revolutionary technology" territory.

The tester's assessment: "The measurements listed here are a bit inflated in my opinion. But nevertheless, StuApp is indeed faster than SQLite."

The Missing Context

What bothers me about the 138x claim isn't that it's wrong—it's probably true for some specific, optimized scenario. What bothers me is that it's presented without the context that would make it useful.

138x faster than SQLite at what, exactly? On what hardware? With what data distribution? For which query patterns? The number sounds impressive until you try to use it to make a decision, at which point it evaporates into marketing fog.

This is classic benchmark inflation. Find the one scenario where your product looks incredible, measure that, then imply that number represents typical performance. I watched Oracle do this in the '90s. I watched NoSQL vendors do it in the 2010s. The technique hasn't changed; just the names.

The Actual Problem Worth Solving

What's genuinely interesting here isn't the speed claims—it's the architectural approach. Embedding an OLAP engine directly in your Node.js process without serialization overhead is a real advantage if you have analytical workloads. The fact that it's built in Rust and can leverage NAPI-RS is legitimately clever.

But (and there's always a but), the Better Stack team hit an immediate practical problem: the npm package doesn't work. As of their testing, installing Stoolap via npm fails with missing native bindings. They had to clone the repo, build from source, and link it manually.

That's not a "cutting-edge technology" problem. That's a "someone forgot to include the compiled binaries in the package" problem. It's the kind of thing that makes the difference between "interesting project" and "tool I can actually use."

Who This Is Actually For

Stoolap isn't a SQLite killer, and to the project's credit, they don't really claim to be. The Better Stack conclusion is fair: "SQLite is still your reliable daily driver for transactions, but Stool app might be your high performance race car for data analysis."

If you're doing heavy analytical queries in a Node.js environment and SQLite is genuinely your bottleneck—not your algorithm, not your data model, but specifically the database engine—then Stoolap might be worth the complexity cost. That's a real but narrow use case.

For most applications, SQLite's "boring" reliability is exactly what you want. It's been in production everywhere for decades. The edge cases are known. The failure modes are documented. It just works.

The Pattern I Keep Seeing

This is maybe the fifteenth time I've seen this exact story arc: new technology built in Rust promises revolutionary performance gains over established tool, real-world testing shows modest improvements in specific scenarios, practical adoption barriers emerge.

Sometimes the new tool finds its niche and thrives. Sometimes it becomes clear the problem it solves isn't actually that common. Sometimes—and I think this might be where Stoolap lands—it's genuinely useful for a specific subset of users but will never replace the incumbent.

The question isn't whether Stoolap is fast. It clearly is, for certain workloads. The question is whether it's fast enough, in enough scenarios, to justify the switching cost and the current rough edges.

Right now, with broken npm packages and benchmark claims that don't match real-world testing, the answer for most developers is probably no. But if they fix the packaging and focus on clearly defining their actual use case rather than claiming to be 138x faster at everything, they might have something.

—Mike Sullivan, Technology Correspondent