Transactions & Concurrency
TransactionsConcurrencyOverview
AetheriusDB gives every transaction full ACID guarantees while letting reads and writes run concurrently without lock contention. Reads see a consistent snapshot, writes commit at a serializable isolation level, and conflicts roll back cleanly for the application to retry. The same model holds as a table grows and as you add nodes.
Why it matters
Section titled “Why it matters”You get the strongest correctness guarantee — serializable — without the usual price of it: readers waiting behind writers. Analytical queries and write traffic run side by side, each on its own consistent view, so a long report never blocks ingestion and ingestion never stalls a report.
- Full ACID, no read locks — reads take a consistent snapshot instead of contending with writers.
- Clean conflict handling — a serialization conflict rolls back with a
well-known code (
40001) for a simple retry, never silent corruption. - Same model at scale — the guarantees hold as a table grows and as you add nodes; you don’t switch consistency models to grow.
How fast it is
Section titled “How fast it is”- Readers and writers don’t wait on each other. Snapshot reads mean a heavy analytical query and a stream of writes proceed in parallel with no lock contention between them.
- Planning stays fast as data grows. Query planning doesn’t degrade with table size, so latency stays predictable from thousands of rows to billions.
This section covers four topics:
- Transaction Isolation —
BEGIN/COMMIT/ROLLBACK, snapshot reads, serializable commits, and handling serialization conflicts (SQLSTATE40001). - Group Tables — one logical table over many children, with content-based routing and atomic write propagation.
- Scaling & Concurrency — how planning stays fast and reads and writes stay contention-free as data grows.
- Raft Coordination — how a multi-node cluster keeps writes safe and survives network partitions.