Python Embedded Database Benchmarks: ObjectBox and SQLite

Performance benchmarks of embedded databases in Python: the object database ObjectBox and SQLite, accessed through popular Python ORMs. Everything runs in-process on local storage, without a database server.

This is a fork of tortoise/orm-benchmarks, the ORM benchmark of the Tortoise ORM project. Changes: ObjectBox added; sync variants of SQLAlchemy and SQLModel added; only persisting is timed (objects and new values are prepared before the timer); a warm-up mode; batch and bulk inserts with 10,000 objects; a large-table mode; fixes to how the suite uses several ORMs (see raw-results/2026-10-18); results are the median of 5 runs.

Older results for PostgreSQL and MySQL (SQL ORMs only, earlier benchmark version, different machine) are in postgres-mysql.md.

Higher is better: rows (objects) per second, as the geometric mean over the 9 object operations of each test (SQLObject has no bulk insert, so its mean covers 8; see Setup). Each value is the median of 5 full runs.

Contents

• Overall results: cold, warm, large table (~20,000 rows)
• Setup: operations, test models
• Detailed results: cold: Test 1, Test 2, Test 3
• Detailed results: warm: Test 1, Test 2, Test 3
• Detailed results: large table (separate page)
• Analysis: cold, warm, large table, key takeaways
• Running the benchmarks

Overall results

Cold

Sync ORMs and ObjectBox run each operation in a fresh process (async ORMs run all operations in one), so the timed part includes one-time costs such as opening the connection, compiling the first statements and filling caches.

Warm

Each operation first runs once untimed in the same process, the database is restored to its state before that run, and then the operation is timed (see Detailed results: warm).

Geometric means, cold vs. warm:

Large table (~20,000 rows)

The same operations, but D–K run on ~20,100 rows instead of ~300: the untimed step that deletes most of the 20,000 rows that Insert: Batch and Insert: Bulk added is skipped (LARGE_TABLE=1). Filter: Large returns ~67x more rows per query, and Update: Whole, Update: Partial and Delete change all rows in one transaction, so its durable commit is spread over ~20,100 rows instead of ~300. Separate runs; detailed tables in large-table.md.

Geometric means, large table, cold vs. warm:

---

Setup

Tested:

Environment: Python 3.14.6, SQLite 3.53.1 (bundled with uv's CPython build), Linux x86_64 (AMD Ryzen 9 5950X, ext4 on NVMe), 100 iterations per operation (Insert: Batch and Insert: Bulk: 10,000 objects), CPU frequency governor performance, 1-minute load average below 1 before each ORM run. Each value is the median of 5 full runs (2026-10-18/19; warm peewee and Tortoise ORM: 5 runs of their own on 2026-10-19 after a fix to the warm-up restore; see raw results, which also lists the changes since the previous results). SQLite runs with synchronous=FULL (its compiled-in default), so every committed transaction is synced to disk, as with ObjectBox.

ObjectBox is an embedded object database with its own storage engine, not an ORM on top of SQL. It uses the 5.0.0b1 beta (on TestPyPI) with its experimental FlatBuffers codegen for writes and reads enabled (OBX_CODEGEN=0 disables it). Differences to the SQL ORMs: Test 2 uses plain indexed ids (the Python binding has no relations), Test 3 stores decimals as strings, JSON as JSON strings (like the SQL ORMs store it as text) and leaves "nullable" columns unset (no NULL support), and Update: Partial writes the whole object.

Operations

The suite also measures fetching a large result set as dicts (G) and as tuples (H) for the SQL ORMs; these aren't object operations, so they're left out of the tables, charts and geometric means (the raw results contain them). ObjectBox has no projection API for them.

Only persisting is timed: the insert operations create the unsaved objects before the timer starts, and the update operations choose the new values before it, so creating objects (including field defaults) and generating test data don't count. SQLObject inserts the row when it creates the object, so for SQLObject only the field values are prepared; peewee's bulk insert prepares row tuples and applies defaults while inserting. Right before the timer starts, each test runs gc.collect() and gc.freeze(), so garbage from the preparation isn't collected while timed.

B and C insert 10,000 objects (BATCH_SIZE); the other operations run 100 iterations. A durable commit costs ~8 ms here, so with 100 objects per transaction (the setting before 2026-10-18) B and C mostly measured that one commit, not the inserts. After B and after C, an untimed step deletes the newest 9,900 rows again, so D–K run on ~300 rows. The large-table results skip that step (LARGE_TABLE=1): D–K run on ~20,100 rows.

Insert: Bulk uses each ORM's fastest bulk path. Only Django (bulk_create()), Piccolo (insert()) and ObjectBox (put() of a list) set the new IDs on the inserted objects. SA ORM and SQLModel, sync and async (bulk_save_objects()), Tortoise ORM and ormar (bulk_create()) and peewee (insert_many() of row tuples) don't: to use the IDs, the objects have to be read back. In SA ORM and SQLModel, session.add_all() does set the IDs, but it inserts row by row, like Insert: Batch. Piccolo and ormar split the insert into chunks within one transaction, as SQLite allows at most 32,766 variables per statement.

Test Models

Test 1 — Simple model (4 fields): id, timestamp, level (indexed), text (indexed)

Test 2 — FK relations: Same as Test 1, plus self-referential foreign key, reverse FK, and M2M relation

Test 3 — Wide model (32+ fields): Same as Test 1, plus 4 sets of 8 typed columns (float, smallint, int, bigint, char, text, decimal, json) — 2 with defaults, 2 nullable

---

Detailed results: cold

SQLite on the local filesystem (/tmp/db.sqlite3), ObjectBox in /tmp/objectbox-bench. SQLite allows one writer at a time, so the benchmark is single-threaded; async ORMs pay overhead without a concurrency benefit. These are cold numbers; see Detailed results: warm for runs with a warm-up run before each operation. The charts per test use a logarithmic scale (rows/sec range from ~50 to ~1,000,000), so equal bar-height differences mean equal ratios.

Test 1: Simple Model (4 fields)

Test 2: FK Relations

Test 3: Wide Model (32+ fields)

Detailed results: warm

In the cold results, each sync ORM runs every operation in a fresh process, so the timed loop also pays one-time costs such as opening a lazily opened connection, compiling the first statements, filling the ORM's caches and, for ObjectBox, compiling its codegen (imports are never timed). These runs use the warm-up mode (WARMUP=1): each operation first runs once untimed in the same process (async ORMs: the same event loop), the database is restored to its state before that run (rows and ID sequences), and then the operation runs again and is timed. Same machine, versions and settings as the cold results; each value is the median of 5 full runs.

Test 1: Simple Model (4 fields)

Test 2: FK Relations

Test 3: Wide Model (32+ fields)

---

Analysis

Cold: ObjectBox about 3x the best SQL ORM

ObjectBox (embedded object database, experimental codegen for writes and reads) has the best geometric mean in all three tests, 2.9–3.4x the best SQL ORM (63,985 vs peewee's 19,539, 61,832 vs peewee's 18,323 and 27,535 vs SA ORM's 9,648). It is fastest in every operation: Get by 4.7–9.9x over the runner-up (SQLObject), Filter: Small by 2.3–3.1x, Filter: Large by 1.3–2.4x; Insert: Batch by 2.5–4.0x, Insert: Bulk by 1.2–1.8x, updates and deletes by 1.8–3.3x; Insert: Single (one synced commit each) by 1.3–1.5x over peewee and Tortoise ORM.

Among the SQL ORMs, peewee has the best geometric mean on Tests 1 and 2, followed by SQLModel and SA ORM; on the wide model (Test 3), SA ORM (9,648) and SQLModel (9,318) are ahead of peewee (8,904). peewee and Tortoise ORM run SQLite in WAL mode, the others with SQLite's default rollback journal: with one durable commit per row, Insert: Single is ~3x faster in WAL mode (160 vs 46–54 rows/sec), so their write results include that advantage. With 10,000 objects per transaction, the insert paths differ much more than with 100: SA ORM and SQLModel insert a batch at ~46,000 rows/sec on Test 1 (peewee ~26,000, Django ~16,000), and each SQL ORM's bulk insert is 2–5x faster than its batch insert (ObjectBox: 1.1–1.3x; its batch insert is already faster than any SQL ORM's bulk insert).

On SQLite, async adds overhead without any concurrency to gain (one writer at a time). The sync variants of SA ORM and SQLModel are 2–5x faster than their async variants on reads, 2.5–7x on batch/bulk inserts and 12–16x on updates and deletes (SA ORM's Delete on Test 2: 3.7x); single inserts, one synced commit each, are about the same. Tortoise ORM is the fastest async ORM, on par with Django (ahead on Tests 2 and 3).

Insert: Bulk returns the new IDs only for Django, Piccolo and ObjectBox (see Operations); the others' bulk paths leave the objects without IDs.

Warm: sync ORMs and ObjectBox gain, the order stays

With a warm-up run, the sync ORMs' geometric means rise by 6–25% (SA ORM and SQLModel most), ObjectBox's by 23–24%; the async ORMs stay within ±4%: they run all operations in one process anyway, so earlier operations already paid most one-time costs. Insert: Single, bound by one synced commit per row, doesn't change. ObjectBox has the best geometric mean in all three tests, 2.9–3.7x the best SQL ORM (79,130 / 76,823 / 33,852 vs peewee's 21,691 / 20,728 and SA ORM's 11,645 on Test 3). Its biggest gains are Update: Whole (2.3–2.9x faster than cold) and Get (1.4–1.7x).

Large table: the commit is amortized, ObjectBox stays ahead

With ~20,100 rows, updates and deletes spread their one durable commit over 67x more rows, so the geometric means rise 1.1–2.9x; ObjectBox again has the best one in all three tests, 2.3–3.2x the best SQL ORM cold (98,011 vs SA ORM's 30,336, 90,446 vs SQLModel's 28,911, 37,444 vs SA ORM's 16,556) and 2.3–3.4x warm. Among the SQL ORMs, SA ORM leads on Tests 1 and 3 and SQLModel on Test 2 (where SA ORM's Delete holds it back); peewee follows. Among the SQL ORMs, SQLObject has the fastest updates; on Test 3 it edges out ObjectBox on Update: Partial (57,789 vs 56,683 rows/sec). peewee is ~10% faster than ObjectBox on Filter: Small on Test 1 (122,009 vs 110,913) and on par on Test 2: ObjectBox's limit/offset query gets slower with ~4,000 instead of ~60 matching rows per level (266k rows/sec on the default table), while SQLite's index scan stops after the offset and 20 rows.

Delete on Test 2 (FK relations) is the slowest operation on the large table for SA ORM (1,143 rows/sec), SA ORM async (1,272), Piccolo (1,434), Tortoise ORM (1,522), ormar (2,169) and Django (2,424), while peewee, SQLModel and SQLObject delete 44,000–102,000 rows/sec. SA ORM and Tortoise ORM get 2.0x and 2.5x slower per row than on ~300 rows (2,236 and 3,874); the likely cause is per-row lookups of related rows (children through the self-reference, M2M links) that grow with the table: in the SA ORM model, the self-referencing parent_id has no index.

One more effect of the larger batches: the rows deleted after Insert: Batch and Insert: Bulk leave free space in the database files, so later writes mostly don't grow the files. For ObjectBox this makes update commits cheaper (fdatasync of the data file ~1.7 ms instead of ~6.2 ms when the file grows), so on Test 1 its Update: Whole and Update: Partial are 1.3x and 1.9x faster than with 100-object batches. A database that has been in use for a while is usually in this state too.

Key takeaways

• ObjectBox: 2.3–3.7x the best SQL ORM's geometric mean (cold, warm and large table); fastest in every operation it runs except, on the large table, Filter: Small on Test 1 (peewee) and Update: Partial on Test 3 (SQLObject, 2% ahead)
• Batch sizes matter: with 100 objects per transaction, batch and bulk inserts mostly measure one durable commit (~8 ms); with 10,000, the SQL ORMs' bulk inserts are 2–5x faster than their batch inserts, and the sync SQL ORMs' batch inserts differ up to 3x
• SQL ORMs on SQLite: peewee and the sync variants of SA ORM and SQLModel are fastest (peewee on the simple models, SA ORM and SQLModel on the wide model and the large table), followed by Django; async adds overhead without any concurrency to gain
• SA ORM async / SQLModel async (aiosqlite): 2–5x slower than their sync variants on reads, 2.5–7x on batch/bulk inserts and 12–16x on updates and deletes. SQLModel tracks closely with SA ORM (expected — it's a thin wrapper around SQLAlchemy)
• Bulk insert and IDs: only Django, Piccolo and ObjectBox set the new IDs on bulk-inserted objects
• Tortoise ORM: the fastest async ORM on SQLite
• ormar: Pydantic validation overhead causes significant slowdown, especially on wide models (Test 3)
• SQLObject: no bulk insert; fast on Get, and the fastest SQL ORM on updates on the large table

Running the benchmarks

# Clone and install
git clone https://github.com/objectbox/python-orm-benchmarks.git
cd python-orm-benchmarks
uv venv --python 3.14 && source .venv/bin/activate
# ObjectBox 5.0.0b1 is only on TestPyPI: install it first, without dependencies
uv pip install --no-deps --index-url https://test.pypi.org/simple/ objectbox==5.0.0b1 objectbox-api==5.0.0b1 objectbox-clib==5.3.2
uv pip install --no-sources -r pyproject.toml

# All ORMs and ObjectBox, Tests 1-3
cd benchmarks
sh bench.sh
# With a warm-up run before each timed operation
WARMUP=1 sh bench.sh
# Large table: D-K on ~20,100 rows
LARGE_TABLE=1 sh bench.sh

For PostgreSQL and MySQL, see postgres-mysql.md.