I wanted to get a sense of how far using SQLite as a database on a reasonably powered server could take me in terms of scale, so I set up some simple benchmarking.

The Setup

I built two identical APIs, one in python using FastAPI and one in Rust using Axum. Each is set up to respond to requests that either initiate reads and writes to an SQLite database. The table's primary key is used in each read request. Both APIs use the same concurrency pattern: all writes are funneled through a single dedicated writer thread, while reads run in parallel. WAL mode is enabled, so readers never block the writer and vice versa.

A "load generator" using a configurable number of concurrent async workers, written in Rust using reqwest + tokio, starts by warming up the db with 1000 entries, and then proceeds to hammer the API with both get requests to retrieve data and post requests to write a new entry into the db. The mix is 90% reads / 10% writes, a rough but I think fair estimation for many web apps. All payloads are 2 KB. While running, the load generator gathers statistics on the time requests take to complete.

To gather useful data I configured the load generator tool to run with (8, 32, 64, 128, 256) workers, sending 50,000 requests at each level. This allows finding the point where the api can no longer handle the load. The server process was pinned to 4 CPU cores and the load generator to the remaining 16 so the two didn't fight for compute.

Methodology

This setup is specific to the use case I want to test. To test the raw performance of SQLite in Rust vs Python, no HTTP api would be involved, however this setup represents my needs by showing me the performance of APIs + SQLite. I ran these tests on my laptop (ThinkPad P15v in power saving mode) to represent a capacity that would be easy to scale to by increasing the specs of the server in the cloud where the applications run.

Results

Python (FastAPI + sqlite3):

Rust (Axum + rusqlite):

This means that the median request completed in 7.99 ms for the Python server and 1.17 ms for the Rust server. Overall the Rust implementation was over 6 times faster despite the fact that the amount of processing required on the request body was minimal.

The similarities in the p99 results between the Python and Rust implementations for higher worker counts suggest where the writes to the database become the limiting factor in the performance of the API.

More to the point, both the Python and Rust implementations of the system were far more than sufficient for my needs.

If the average user sends a request every 10 seconds while using a web application, then a single (admittedly fairly powerful) server could handle ~11,000 active users with the Python implementation or ~66,000 active users with the Rust implementation.

This doesn't account for spikes in traffic but it is still such a large threshold that I am confident to keep doing what I am doing.

Caveats / Conclusion

Admittedly, this setup is in the ideal scenario. I did not test anything external to the backend examples, nor did I include a simulation of more complex processing that needs to happen to the data before inserting or sending. I'd also like to build out more complete tests in the future, like more complex database schemas, serving large amounts of static content, and websocket based workloads.

In the future I might cover how to scale a SQLite setup like this to multiple servers with read replicas of the database.

But, for now this is sufficient to make me confident to continue launching projects this way, and much more intrinsically satisfying than paying a middleman or maintaining a postgres database myself for hobby projects.

note:

To get data for the cover image, I ran the same system with [8, 10, 13, 16, 20, 25, 32, 40, 51, 64, 81, 102, 128, 161, 203, 256] workers.

another note:

code is here.

The first area of the customizer tool allows selection of color, typography, and layout PRESETS. They are the fastest way to see the site styling shift. For more fine grained changes color, typography, and layout can be changed in the section below. You can even save your customizations to presets.

The header image of this post is an svg composed of shapes colored directly through the css variables, so that when the color settings for the site change, the svg changes too.

I'm launching this in production on this site, as it is a fun novelty here. However, especially for simple static sites, adding something similar to this could really speed up refinement of style changes or allow someone other than the developer to propose exactly what they want before a site goes live.

Try the customizer

Like my other experimental projects, the only front end dependencies were kept minimal. The only library imported for this project is a web assembly implementation of the Box 2D physics engine. All artwork is done through drawing directly to an HTML canvas using the browser's canvas API.

The part that was expectedly challenging was the creation of the free form level designer. The functionality for adding, reshaping, and moving the various shapes, and configuring their physics properties required some careful planning.

The part that was unexpectedly challenging was getting the "marbles" to roll smoothly down a curved line. I started with the rapier.js physics engine, but consistently ran into issues with "ghost collisions" when trying to get a marble to roll down a curved line. Smooth rolling curved surfaces was a requirement though, because I wanted people to be able to make neat loops and curved ramps. I really enjoyed working with the Rapier physics engine, and I am going to use it for other projects in the future (it is very good), but I was forced to move to the Box 2D Physics engine, which provides the option to chain shapes (as long as they are static). Once I adopted this approach the smooth rolling over curves worked, and high speed loops could be created without the marbles randomly jittering or springing off tangential to the line.

All the building and terrain art are drawn directly in javascript using the canvas api. Rather than redrawing every hex and building each time from scratch, since this would be very expensive, the drawing system pre-renders each visual component once and stores it to an offscreen canvas. These can then be "stamped" to the main canvas in a loop, making the process much faster. To allow for animation of the buildings, the building stamps are generated fresh each frame.

The system that drives the simulation is very simple. Buildings produce resources corresponding to their type. Trains move along the tracks, randomly branching at intersections or following the track with the highest priority (player configurable). The pickup and delivery system works by checking if a train has crossed the midpoint of hex edge adjacent to a building which produces or consumes resources. If the building has room for resources it consumes and the train has them, they get sent to the building; if the building has produced resources and the train has cargo space they get sent there. Buildings produce and consume resources as the simulation updates.