Lock-free reads at scale.
StaxDB serves every read without a lock, in both the index and storage. Read throughput grows with every core you add, even under heavy writes.
Measured performance.Published benchmarks.
Every figure is a measured benchmark on named hardware, against the rival named beside it.
- Relational and document joins, against SQLite
- 48x
- 4 KiB persistent allocations, against mimalloc
- 18x
- Sequential and ordered reads, against std::map
- 15x
- Mixed read and write workloads, against LMDB
- 1.6x
The command, the commit and the machine of every benchmark are on staxdb.com/performance.
Seven purpose-built layers.One integrated engine.
From memory allocation to SQL and vector search, StaxDB's layers are designed to work together, and each one speeds up the layer above it.
- L7TurboVectorVectorsVector search, geo queries, and RAG retrieval built into the core engine.There is no outside service to bolt on and no second copy of your data to keep in sync.
- L6TurboJSRuntimeCompute right next to your data.JavaScriptCore runs inside the storage engine, so your code works directly on stored records with no network round trip in between.
- L5TurboSQLSQLMariaDB-compatible SQL for tables and documents.You can join schema-free collections and structured tables in a single query, and TurboSQL runs those joins far faster than SQLite.
- L4TurboHeapObjectsZero-deserialization object storage.There is no JSON to parse and no bytes to decode. TurboHeap stores objects in the exact layout your code reads, so even a nested field is a single jump away.
- L3TurboCoreStorageWrite-once, in-place storage.There is no log replay and no background compaction storms on your disk. TurboCore writes every record once, at its final address, and keeps it through a hard crash.
- L2TurboMapIndexHash-map speed with every key in order.You no longer have to choose between fast lookups and range scans. TurboMap outperforms Google's flat hash map and keeps every key in order.
- L1TurboAllocAllocatorA persistent allocator built for raw speed.TurboAlloc manages memory directly inside the database file and still outperforms the leading in-memory allocators.
Fewer copies. Fewer round trips.Faster execution.
A traditional database sits at the far end of a network connection. Every query string is parsed, pages are locked, and rows are copied between processes. StaxDB removes those layers and runs your code directly on the stored record.
Zero-copy persistence.
Log-structured engines write your data over and over: to the log, to sorted files, and again during every compaction. StaxDB writes each record once, in place, so your full disk bandwidth goes to your workload instead of housekeeping.
Zero serialization tax.
StaxDB stores objects in the same form your code uses. Every field is a single jump away, and there is nothing to pack or unpack.
No log replay on restart.
TurboAlloc's memory is the database file itself. When the server restarts, there is nothing to rebuild and nothing to replay.
One engine.Your app's essential services.
Data, functions, users, realtime, files, search, ledger, sites and versions run on the same engine. One key reaches all of it over HTTP, MCP, the CLI and the JS SDK.
Database
Every document collection is also a SQL table, so you can query your JSON with SQL.
TurboCore, TurboSQLFunctions
Run JavaScript right beside your data for triggers, validation, and complex updates, with no network in between.
TurboJSUsers
Sign-in, roles and permissions belong to the platform and are decided before your code runs.
SubstrioRealtime
Pub/sub and live sync stream each change to the clients watching it.
SubstrioFiles
Files and media are stored beside the records that name them, in the app’s own storage.
SubstrioSearch
Run semantic search, RAG retrieval, and geo queries right beside your transactional data.
TurboVectorLedger
Money is a platform service: each balance is kept as it changes and read in one load.
SubstrioSites
Your site is served by the same binary, with its own TLS certificates and your domains.
SubstrioVersions
Every app has one history: branches, commits, promote and rollback.
SubstrioIsolation built into the architecture.
Every app gets a separate database file, a separate JavaScript heap and a fixed memory budget. There is no shared table and no tenant filter to forget.
StaxDB stores each app's data in a separate database file.
Each app's database file is opened only for that app. No shared table with a tenant column exists, so no missed filter can leak a row.
Isolated heaps for JavaScript.
Each app's functions are executed in a separate JavaScriptCore context group, with a separate heap and garbage collector. There is no direct call path from one app's code into another's.
A fixed memory budget for every app.
An app's heaps are reserved against one budget before they exist, and native bytes are charged to that budget where they are allocated. A call past the budget fails with a typed error, and a neighbour's share is never touched.
Separate processes for tools.
Each command line tool bundled with an app is executed as a separate process, its memory walled off by the CPU's page tables, behind eleven kernel walls.
The server runs jailed too.
Before any configuration or key is read, one small launcher process for tools is started, then the server process is locked down by Landlock for good: no program can be run from it, and no other process can be traced or read from it. If the lockdown fails, startup is aborted.
Memory is never freed under a running read.
TurboAlloc reuses a slot only after every read of it has finished, so no read is ever served memory freed mid-read.
Every layer of StaxDB's data path was written by hand, from the allocator up.
Many databases that claim to be built from scratch still sit on standard allocators and borrowed storage engines whose internals are public and well studied.
- StaxDB's own memory allocator. TurboAlloc allocates the memory for every record inside the database file, in place of the system allocator.
- StaxDB's own data core and storage engine. TurboMap and TurboCore are written by hand, line by line, and inherit nothing from an older engine.
Build on the enginebehind the benchmarks.
Every app on Substrio runs on StaxDB from its first deploy.