Stoolap vs. SQLite: Comparing Rust OLAP and Traditional OLTP Databases

Stoolap is a high-performance, embedded SQL database engine written entirely in Rust, designed specifically for fast analytical queries. When starting a new software project, one of the first and most critical architectural decisions is choosing the right database. For developers working with local or embedded data, the choice has often been simple: SQLite. However, as applications grow, data volumes swell, and the complexity of queries intensifies, the limitations of traditional solutions like SQLite can become a significant performance bottleneck.

This article explores Stoolap, a new player in the embedded database space that aims to solve these problems. You'll discover the architectural choices that make it so fast, including key concepts like OLAP vs. OLTP, Multi-Version Concurrency Control (MVCC), and the magic of its native Node.js integration through NAPI-RS, which eliminates performance-killing serialization overhead. You'll also see a series of live benchmark tests, putting Stoolap head-to-head with SQLite to see if it truly lives up to its claims of 100x performance improvements.

What is Stoolap? A modern alternative for analytical workloads

At its core, Stoolap is an embedded OLAP (Online Analytical Processing) database. This distinction is crucial and sets it apart from many databases you might be used to. To fully appreciate what Stoolap offers, it's important to understand the fundamental difference between OLAP and OLTP systems.

Understanding OLAP vs. OLTP databases

Most standard application databases, including SQLite, PostgreSQL, and MySQL, are classified as OLTP (Online Transaction Processing) systems. OLTP databases are optimized for managing transactional data. Think of them as the backbone of your application's day-to-day operations. They excel at handling a large number of short, fast transactions like creating a user, updating an order, or deleting a post (CRUD operations: Create, Read, Update, Delete). They are designed for high-throughput, read/write operations that affect a small number of records at a time. Data integrity and consistency are paramount.

OLAP (Online Analytical Processing) systems are designed for a completely different purpose. OLAP databases are optimized for complex queries and data analysis. They are built to answer business intelligence questions by aggregating vast amounts of data. Think of them as the engine for your analytics dashboard or reporting tool. They excel at handling a small number of very complex, read-heavy queries that scan millions or even billions of rows. Queries often involve aggregations (SUM, COUNT, AVG), groupings, and complex joins.

Stoolap fits firmly in the OLAP category. It brings the analytical power of large-scale data warehouses like Google BigQuery or specialized engines like DuckDB into a portable, embedded format, much like SQLite.

The power of Rust and zero serialization overhead

Stoolap is built from the ground up in Rust, a modern systems programming language renowned for its "blazing-fast" performance and memory safety guarantees. This foundation allows Stoolap to perform complex computations with maximum efficiency, without the overhead of garbage collection found in other languages.

However, the real game-changer for Node.js developers is Stoolap's native driver. Usually, when a Node.js application needs to communicate with a database engine written in a different native language like Rust or C++, it must cross a "bridge." This process involves serialization (converting JavaScript data into a standardized format like JSON), transmission (sending this data to the native database engine), deserialization (the native engine parsing the data), and the reverse process for results.

This constant back-and-forth of serialization and deserialization creates serialization overhead, a significant performance bottleneck that can slow down your application.

Stoolap ingeniously bypasses this entire problem by using NAPI-RS. This is a powerful framework that compiles the Rust database engine into a native Node.js addon. This addon loads directly into your Node.js process, allowing JavaScript to call the Rust functions directly without any bridge or data conversion. They essentially share the same memory space, enabling data to be passed between Node.js and Rust at near-zero cost. This is the secret behind its claim of "no HTTP server in between, no serialization overhead."

The architecture behind Stoolap's speed

Stoolap's impressive performance isn't just due to its Rust foundation and native integration. It employs several advanced database architecture principles designed to maximize speed and efficiency for analytical queries.

Concurrent operations with MVCC

One of the main limitations of SQLite is its locking mechanism. When a process needs to write to the database, it places a lock on the entire database file, preventing any other process from reading or writing until the transaction is complete. This can become a major bottleneck in applications with any level of concurrency.

Stoolap uses MVCC (Multi-Version Concurrency Control). Instead of locking data, MVCC maintains multiple versions of data rows. When a transaction begins, it is given a snapshot of the database at that moment in time. Readers don't block writers (a read query can access its snapshot without being blocked by a concurrent write operation), and writers don't block readers (a write operation creates a new version of a row instead of overwriting it). This allows for a much higher degree of concurrency, as multiple read and write operations can happen simultaneously without waiting for each other.

Unleashing multi-core power with parallel execution

Modern computers all have multi-core CPUs, but many programs, including SQLite, are fundamentally single-threaded. This means they can only use one CPU core at a time, leaving the rest of your processor's power untapped.

Stoolap is designed for the multi-core era. It uses a smart work-stealing scheduler called Rayon to automatically parallelize query execution. When you run a large, complex query, Stoolap breaks it down into smaller, independent tasks (like filters, joins, or aggregations) and distributes them across all available CPU cores. This allows your machine to throw its full processing power at the query, drastically reducing execution time for heavy analytical workloads.

Intelligent query planning with a cost-based optimizer

Finally, Stoolap doesn't just execute your SQL queries blindly. It employs a sophisticated Cost-Based Optimizer, similar to those found in enterprise-grade databases like PostgreSQL. Before running a query, the optimizer analyzes it, examines statistics about the data (like table sizes and data distribution), and evaluates multiple possible execution plans. It estimates the "cost" (in terms of I/O and CPU usage) of each plan and intelligently chooses the most efficient path to retrieve your results. This ensures that even complex queries are executed in the most optimal way possible.

Setting up the benchmark

Putting Stoolap to the test reveals how it performs against the popular better-sqlite3 library.

Project initialization

Create a new project directory and initialize a Node.js project. Open your terminal and create a new folder for the test project:

mkdir stoolap-benchmark-test

cd stoolap-benchmark-test

Run the npm init command to create a package.json file. You can press Enter to accept the defaults for all prompts:

npm init -y

This file will track the project's metadata and dependencies.

Installing the dependencies

Install the Node.js drivers for both Stoolap and SQLite:

npm install @stoolap/node better-sqlite3

Important workaround: building Stoolap from source

As of the time of this writing, the @stoolap/node package on NPM has an issue where it may fail to install the correct pre-compiled native binary for your system, resulting in an error like Error: Cannot find native binding. This is a temporary hiccup for an early-stage project. Fortunately, you can work around this by building the package from source.

If you encounter this issue, follow these steps. First, ensure you have the Rust toolchain installed on your machine. You can get it from rustup.rs. Next, go to a separate directory and clone the stoolap-node repository from GitHub:

git clone https://github.com/stoolap/stoolap-node.git

Navigate into the cloned repository and run the build command. This will compile the Rust engine into a native addon:

cd stoolap-node

npm install

npm run build

This process might take a few minutes as it compiles all the Rust code. Go back to your stoolap-benchmark-test project directory and install the package by pointing to the local directory you just built:

cd ../stoolap-benchmark-test

npm install ../stoolap-node

This will use your locally compiled version instead of the one from the NPM registry, resolving the binding issue.

The performance showdown: Stoolap vs. SQLite in action

With the project set up, writing benchmark scripts reveals the performance differences. Two tests will be performed based on the operations where Stoolap claims its biggest victories.

Test 1: the COUNT DISTINCT challenge

The Stoolap blog claims a massive 138x speedup on COUNT DISTINCT operations. Testing this claim reveals the actual performance difference.

Create a new file named benchmark.mjs (using the .mjs extension to use modern ES Module syntax). Paste the following code into benchmark.mjs. This script sets up in-memory databases, seeds them with 100,000 rows of sales data, and then times a complex analytical query:

import { Database as Stoolap } from "@stoolap/node";
import SQLite from "better-sqlite3";

const ROW_COUNT = 100000;

async function runBenchmark() {
  console.log(
    `\n🚀 Seeding ${ROW_COUNT.toLocaleString()} rows into both databases...`,
  );

  // 1. Setup Stoolap (In-Memory)
  const sdb = await Stoolap.open(":memory:");
  await sdb.execute(
    "CREATE TABLE sales (id INTEGER PRIMARY KEY AUTO_INCREMENT, user_id INTEGER, amount FLOAT, category TEXT)",
  );

  // 2. Setup SQLite (In-Memory)
  const qdb = new SQLite(":memory:");
  qdb.exec(
    "CREATE TABLE sales (id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER, amount FLOAT, category TEXT)",
  );

  // 3. Prepare mock data
  const categories = ["Electronics", "Books", "Clothing", "Home", "Garden"];
  const mockData = Array.from({ length: ROW_COUNT }, () => ({
    user: Math.floor(Math.random() * 1000),
    amt: Math.random() * 100,
    cat: categories[Math.floor(Math.random() * categories.length)],
  }));

  // 4. Perform Inserts and time them
  console.time("Stoolap Seed");
  for (const row of mockData) {
    await sdb.execute(
      "INSERT INTO sales (user_id, amount, category) VALUES ($1, $2, $3)",
      [row.user, row.amt, row.cat],
    );
  }
  console.timeEnd("Stoolap Seed");

  console.time("SQLite Seed");
  const qInsert = qdb.prepare(
    "INSERT INTO sales (user_id, amount, category) VALUES (?, ?, ?)",
  );
  const qTransaction = qdb.transaction((data) => {
    for (const row of data) qInsert.run(row.user, row.amt, row.cat);
  });
  qTransaction(mockData);
  console.timeEnd("SQLite Seed");

  console.log(`\n--- ✨ STARTING PERFORMANCE RACE ---`);

  // The "Stoolap Killer" Query: Analytical COUNT DISTINCT with Grouping
  const complexQuery = `
    SELECT category, COUNT(DISTINCT user_id) as unique_users
    FROM sales
    GROUP BY category
    ORDER BY unique_users DESC
  `;

  // 5. Test SQLite
  const startSQLite = performance.now();
  qdb.prepare(complexQuery).all();
  const endSQLite = performance.now();
  console.log(`SQLite Time: ${(endSQLite - startSQLite).toFixed(3)}ms`);

  // 6. Test Stoolap
  const startStoolap = performance.now();
  await sdb.query(complexQuery);
  const endStoolap = performance.now();
  console.log(`Stoolap Time: ${(endStoolap - startStoolap).toFixed(3)}ms`);

  // 7. Calculate and display the result
  const speedup = (endSQLite - startSQLite) / (endStoolap - startStoolap);
  console.log(
    `\n🔥 RESULT: Stoolap is ${speedup.toFixed(2)}x faster for this query!`,
  );

  await sdb.close();
  qdb.close();
}

runBenchmark().catch(console.error);

Execute the script from your terminal:

node benchmark.mjs

You'll see output showing the time taken to seed the data and, more importantly, the time taken to execute the analytical query.

In the test with 100,000 rows, Stoolap was about 4.12x faster than SQLite. This is a solid improvement but a far cry from the advertised 138x. The discrepancy likely comes from different test environments, data shapes, and hardware.

Scaling up reveals that the performance gap often widens. Change the ROW_COUNT constant at the top of the file to 1000000 (one million) and run the test again. With a larger dataset, Stoolap's advantage grew to about 6.47x faster. This demonstrates that its architecture is better suited for scaling to larger analytical workloads.

Test 2: the DISTINCT + ORDER BY race

Another operation highlighted for its performance is combining DISTINCT with ORDER BY. This forces the database engine to perform a full table scan, deduplicate the results, and then sort them—a computationally intensive task.

Create a second script, benchmark2.mjs, with the following code. This test will simulate querying log data:

import { Database as Stoolap } from "@stoolap/node";
import SQLite from "better-sqlite3";

const ROW_COUNT = 100000;

async function runDistinctBenchmark() {
  console.log(`\n🚀 Seeding ${ROW_COUNT.toLocaleString()} log entries...`);

  // Setup databases
  const sdb = await Stoolap.open(":memory:");
  await sdb.execute(
    "CREATE TABLE logs (id INTEGER PRIMARY KEY AUTO_INCREMENT, ip_address TEXT, status_code INTEGER, payload TEXT)",
  );
  const qdb = new SQLite(":memory:");
  qdb.exec(
    "CREATE TABLE logs (id INTEGER PRIMARY KEY, ip_address TEXT, status_code INTEGER, payload TEXT)",
  );

  // Mock data generation
  const ips = Array.from({ length: 50 }, (_, i) => `192.168.1.${i}`);
  const codes = [200, 201, 400, 404, 500];
  const mockData = Array.from({ length: ROW_COUNT }, () => ({
    ip: ips[Math.floor(Math.random() * ips.length)],
    code: codes[Math.floor(Math.random() * codes.length)],
    payload: "some log data",
  }));

  // Seed data
  console.time("Stoolap Seed");
  for (const row of mockData) {
    await sdb.execute(
      "INSERT INTO logs (ip_address, status_code, payload) VALUES ($1, $2, $3)",
      [row.ip, row.code, row.payload],
    );
  }
  console.timeEnd("Stoolap Seed");

  console.time("SQLite Seed");
  const qInsert = qdb.prepare(
    "INSERT INTO logs (ip_address, status_code, payload) VALUES (?, ?, ?)",
  );
  const qTransaction = qdb.transaction((data) => {
    for (const row of data) qInsert.run(row.ip, row.code, row.payload);
  });
  qTransaction(mockData);
  console.timeEnd("SQLite Seed");

  console.log("\n--- ✨ STARTING DISTINCT + ORDER BY RACE ---");

  // This query forces a full table scan, deduplication, and a sort
  const distinctQuery = `
    SELECT DISTINCT ip_address, status_code
    FROM logs
    ORDER BY ip_address ASC, status_code DESC
  `;

  // 1. SQLite Run
  const startSQLite = performance.now();
  const qResult = qdb.prepare(distinctQuery).all();
  const endSQLite = performance.now();
  console.log(
    `SQLite Time: ${(endSQLite - startSQLite).toFixed(3)}ms (found ${qResult.length} unique pairs)`,
  );

  // 2. Stoolap Run
  const startStoolap = performance.now();
  const sResult = await sdb.query(distinctQuery);
  const endStoolap = performance.now();
  console.log(
    `Stoolap Time: ${(endStoolap - startStoolap).toFixed(3)}ms (found ${sResult.length} unique pairs)`,
  );

  const speedup = (endSQLite - startSQLite) / (endStoolap - startStoolap);
  console.log(
    `\n🔥 RESULT: Stoolap is ${speedup.toFixed(2)}x faster for this query!`,
  );

  await sdb.close();
  qdb.close();
}

runDistinctBenchmark().catch(console.error);

Run the new script:

node benchmark2.mjs

In this test, Stoolap was still faster, but by a much smaller margin of about 1.5x. This is again less than the advertised 14x but still demonstrates a consistent performance advantage in these types of complex, multi-stage queries.

Analyzing the results: when to choose Stoolap

The benchmark tests confirm that Stoolap delivers on its promise of being faster than SQLite for complex, analytical queries. However, the dramatic numbers from its marketing materials should be taken with a grain of salt, as performance can vary greatly depending on the specific query, data structure, and hardware.

Where Stoolap shines

Stoolap is the clear winner for analytical and complex queries, especially on larger datasets. If your Node.js application needs to perform in-app analytics, generate reports, or run BI-style queries on a local dataset without the overhead of a separate data warehouse, Stoolap is an exceptional choice. Its parallel execution and MVCC architecture are built for exactly these scenarios.

Where SQLite still wins

As the Stoolap author honestly admits, SQLite still has the edge in simple, single-row, transactional operations. For tasks like fetching a user by their ID, updating a single record, or performing simple inserts, SQLite's B-tree page cache and decades of optimization for point lookups make it incredibly fast. It remains the undisputed king for general-purpose application data storage where fast, small transactions are the norm.

Final thoughts

So, is Stoolap the "SQLite killer" it's been hyped up to be? The answer is a clear no. More accurately, it's not trying to be. Stoolap and SQLite are two different tools built for two different jobs. SQLite is your reliable, all-purpose hammer for transactional tasks, while Stoolap is a high-performance power tool precision-engineered for data analysis.

What is truly exciting is that a pure-Rust, high-performance analytical engine can now be seamlessly integrated into a Node.js project thanks to NAPI-RS. This opens up new possibilities for building data-intensive applications directly within the Node.js ecosystem. While the project is still in its early days, as evidenced by the NPM installation bug, its core technology is sound and incredibly promising. If you're building an application that needs to crunch numbers and perform complex queries locally, Stoolap is definitely a project to watch and a powerful tool to have in your arsenal.

Got an article suggestion? Let us know

Next article

A Look Into Claude Opus 4.5

Claude Opus 4.5 combines state-of-the-art coding performance with 67% lower pricing. Learn how it dominates software engineering benchmarks and generates complete applications from single prompts.

→

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.