bench package - modernc.org/sqlite-bench - Go Packages

The SQLite Drivers 26.05 Benchmarks Game

This repository is a modification of go-sqlite-bench, forked at 4df8bfd.

Category: database/sql drivers

For the non database/sql drivers category please see modernc.org/sqlite-bench2

[[TOC]]

Drivers

These drivers are benchmarked

mattn, github.com/mattn/go-sqlite3@v1.14.44, a CGO-based solution.
modernc, modernc.org/sqlite@v1.50.1, a pure Go solution based on the SQLite C code transpilled to Go using ccgo/v4.
ncruces, github.com/ncruces/go-sqlite3@v0.34.2, a pure Go solution using wasm2go.

Go version: go1.26.2

A general note on benchmarks and this repository

Do not trust benchmarks, write your own. These specific benchmarks are modelled after someone's very own database usage scenarios. Your scenarios may be totally different.

Each test is run twice, the recorded values are the averages of the two runs. This is not very scientific.

Database Schema

The test database consist of the following tables and indices:

PRAGMA journal_mode=DELETE;
PRAGMA synchronous=FULL;
PRAGMA foreign_keys=1;
PRAGMA busy_timeout=5000;

CREATE TABLE users (
    id INTEGER PRIMARY KEY NOT NULL,
    created INTEGER NOT NULL,
    email TEXT NOT NULL,
    active INTEGER NOT NULL);
CREATE INDEX users_created ON users(created);

CREATE TABLE articles (
    id INTEGER PRIMARY KEY NOT NULL,
    created INTEGER NOT NULL,  
    userId INTEGER NOT NULL REFERENCES users(id),
    text TEXT NOT NULL);
CREATE INDEX articles_created ON articles(created);
CREATE INDEX articles_userId ON articles(userId);

CREATE TABLE comments (
    id INTEGER PRIMARY KEY NOT NULL,
    created INTEGER NOT NULL,
    articleId INTEGER NOT NULL REFERENCES articles(id),
    text TEXT NOT NULL);
CREATE INDEX comments_created ON comments(created);
CREATE INDEX comments_articleId ON comments(articleId);

Benchmark Results

Result times are measured in milliseconds. Lower numbers indicate better performance.

Simple Benchmark

Insert 1 million user rows in one database transaction. Then query all users once.

Complex Benchmark

Insert 200 users in one database transaction. Then insert 20000 articles (100 articles for each user) in another transaction. Then insert 400000 comments (20 comments for each article) in another transaction. Then query all users, articles and comments in one big JOIN statement.

Many Benchmark

Insert N users in one database transaction. Then query all users 1000 times. This benchmark is used to simluate a read-heavy use case.

Large Benchmark

Insert 10000 users with N bytes of row content. Then query all users. This benchmark is used to simluate reading of large (gigabytes) databases.

Concurrent Benchmark

Insert one million users. Then have N goroutines query all users. This benchmark is used to simulate concurrent reads.

4GB RAM builders

On 32 bit architectures and on the linux/ppc64le builder - to avoid OOM

the Large benchmark uses 2.5k users instead of a 10k.
the Concurrent benchmark uses 250k users instead of a million.

Caveat emptor

Mistakes happen. If you find anything wrong about the results please report the problem at the issue tracker, thank you.

tl;dr: Scorecard

The best time in every test, shown in bold in the tables below individual graphs, is worth one point. The scorecard shows where and how many points were awarded to each benchmarked package.

Total score ties are ranked alphabetically. Please read those as one shared rank.

This score is an ad hoc aggregate metric. Its usefulness is possibly at most in showing how the scores may evolve in time when new, improved versions of packages will get benchmarked.

The time results for the particular OS and HW provide a more detailed info.

	Total	Simple	Complex	Many	Large	Concurrent
1. mattn	`126`	`22`	`29`	`30`	`25`	`20`
2. ncruces	`46`	`4`	`2`	`6`	`21`	`13`
3. modernc	`36`	`6`	`1`	`12`	`2`	`15`

Disclaimer: The score and the ranking do not show how will any package perform in your particular application on a particular system. Additionally, empirically the scores fluctuate as much as about +/- 10 points. It's complicatd to better stabilize the results to be more precise and reliable. On some machines the tests run for many hours already with n = 2.

Results: darwin/amd64

OS: macOS Tahoe 26.4
CPU: Apple M1, 2020
GOMAXPROCS: 8
RAM: 8GB
Disk: APPLE SSD AP0256Q Media (251GB)

darwin/amd64-simple-png