Scaling & Concurrency
What it is
Section titled “What it is”AetheriusDB partitions each table automatically along a sort key you choose. As a partition grows large or hot, the engine splits it online — without blocking writers and while preserving the global sort order, so range scans stay sequential. The table behaves identically before and after a split; you never manage partitions by hand.
The same model keeps query planning fast. Instead of scanning catalog tables to estimate how much data a query will touch, the planner reads compact pre-computed statistics kept alongside the data. Planning time stays roughly flat as the table grows, so a query over a very large table plans about as fast as the same query over a small one.
Why it matters
Section titled “Why it matters”Most databases get slower per query as they get larger: the catalog grows and lock contention rises. AetheriusDB avoids both — hot partitions split themselves, planning stays fast, and concurrent readers never block writers (see Transaction Isolation).
- No manual sharding — add capacity and partitions rebalance themselves.
- Sequential scans preserved — splits keep the global sort order intact.
- Fast planning at scale — compact statistics replace catalog table scans.
flowchart LR
classDef cube fill:#1f2640,stroke:#7c5cff,color:#e8eaf0
classDef split fill:#1f2640,stroke:#00d4ff,color:#e8eaf0
classDef out fill:#1f2640,stroke:#4ade80,color:#4ade80
P1[Partition]:::cube --> CHECK{Size watcher}
CHECK -- under limit --> KEEP[Keep as-is]:::out
CHECK -- over limit --> SPLIT[Split online<br/>along sort key]:::split
SPLIT --> P2[Partition A]:::cube
SPLIT --> P3[Partition B]:::cube
How you use it
Section titled “How you use it”Scaling is mostly invisible — you write SQL and the engine handles partitioning. The main thing you choose is the sort key when you create a table.
-- Declare a sort key. Partitions split along this axis,-- so range scans on it stay sequential as the table grows.CREATE TABLE events ( id BIGINT, occurred_at TIMESTAMP, payload TEXT)SORT BY (occurred_at);
-- Approximate counts answer near-instantly from precomputed statistics,-- without scanning rows.SELECT APPROX_COUNT(*) FROM events;Exact aggregates work as usual — they simply read more data. Use APPROX_COUNT
when a fast, bounded-error answer is good enough.
In a multi-node cluster this scale-out behaviour rides on the same coordination that lets compute nodes share one data plane safely; see Distributed Execution.