Name: AngaraBase
Author: AngaraBase

What is AngaraBase

Most databases operate on the principle "accept everything until we crash". That gives fast demos and painful on-call nights. AngaraBase reverses the model: every resource boundary is declared in code, measured by a metric, and trips before production breaks. We are not the fastest at everything — we are the most predictable, and we prove it with soak tests, not promises.

AngaraBase is a ground-up OLTP engine written in Rust for Linux. It speaks the PostgreSQL wire protocol, so existing drivers, ORMs and tools (psql, pgcli, DBeaver) connect without changes. Under the hood the storage layer uses an UNDO-log MVCC model inspired by Oracle and InnoDB — no VACUUM, no heap bloat, bounded version chains. Recovery follows the textbook ARIES algorithm (Analysis → Redo → Undo + CLR). The engine is modular: pluggable table engines support row storage, in-memory tables, and a production-preview columnar engine (AngaraColumn) for HTAP workloads with full DML and SIMD aggregations.

Architecture

Client/Driver ──pgwire──▸ Protocol Adapter (angarabased)
                              │
                        SQL + session ctx
                              │
                        Query Pipeline (CBO → IR Executor)
                              │
                        Txn Manager (snapshots, watermarks)
                              │
                        Storage Manager ──▸ engine dispatch
                        ┌─────┼─────────────────┐
                   HeapStore  AngaraMemory  AngaraColumn
                   + BufferPool              (columnar segments)
                   + UndoStore
                        │
                   WAL / ARIES Recovery
                        │
                   AngaraIO (fsync contract)

Single-file storage

One .adb file per database, shared buffer pool, up to 65 535 tables. Simple to back up, copy, and restore — data directory is a portable artifact.

Pluggable engines

The TableEngine trait dispatches to row (HeapStore), in-memory (AngaraMemory), and columnar (AngaraColumn) backends. HTAP routing across row + column is planned.

PostgreSQL protocol

pgwire compatibility: connect with psql, any PostgreSQL driver, or ORM. No proprietary client needed — zero migration friction.

Linux-native by design

One OS, tuned for it: io_uring, direct I/O, zero-copy networking. No cross-platform compromises — performance and predictability first.

Core engineering principles

UNDO-log MVCC

Oracle/InnoDB-style versioning. Old row versions live in a bounded UNDO chain, not in the heap. No VACUUM process, no table bloat, predictable storage footprint. Dead versions are garbage-collected by AngaraGC epoch-based reclaim.

Fail-closed by contract

Eight resource boundaries — buffer pool, write-set, UNDO budget, memory tables, snapshot age, connections, statement timeout, I/O queue — each with a config knob, an explicit SQLSTATE, and a Prometheus metric. When a limit is hit, the system rejects cleanly — it never degrades silently.

ARIES recovery

Write-ahead log with full ARIES protocol: Analysis phase scans the log, Redo replays committed changes, Undo rolls back incomplete transactions using CLR (Compensation Log Records). Textbook durability, implemented and tested in every release.

Evidence gates

Every release train ships with a soak test and a pinned benchmark. Results are published in evidence packs — not marketing claims. Public RFC process, G2 review gates, and architecture decision records keep the project honest.

SIMD-vectorized executor

AngaraVector processes queries in batches of 1024 rows using SIMD instructions through std::simd. SelectionVector enables zero-copy filters; Hash Join and aggregations run on a vectorized pipeline. 1.2–2.7× speedup on analytical queries vs row-store, measured on NVMe.

Built in Rust

Memory safety without a garbage collector. No data races by construction. Fearless concurrency in the storage layer. Compile-time guarantees reduce the class of bugs that matter most in a database: silent corruption, use-after-free, undefined behavior.

Observability first

Every component exposes metrics, wait events, and USDT probes. Fail-closed boundaries are not just enforced — they are visible: angarabase_txn_writeset_rejects, angarabase_undo_rejects_total, angarabase_conn_rejects_total, and more. Grafana-ready out of the box.

Performance

Pinned benchmarks vs PostgreSQL 18 on our golden_db harness (NVMe, 16 vCPU, Linux). Every number ships with a fixed evidence pack — no rounding, no averaging away outliers:

×3.1 on durable TPS

Group-commit fsync coalescing: 453 TPS for AngaraBase vs 146 TPS for PostgreSQL 18 on a commit-bound workload.

×1.2–2.7 on aggregations

force_vector vs row-store on typical analytical queries through AngaraVector.

p99 < 1 ms

Point lookup p99 = 0.256 ms on the current debug build; release builds are expected to be faster.

≤ 1 fsync per TX

WAL fsync amplification per commit-record — achieved through sync_at_commit group-commit.

At a glance

	PostgreSQL	Oracle	AngaraBase
MVCC model	Heap MVCC + vacuum	UNDO (commercial)	UNDO-log MVCC
Vacuum / cleanup	VACUUM workload	Background tasks	No VACUUM
License	PostgreSQL License	Proprietary	Open source
Language	C	C / C++	Rust
Wire protocol	pgwire (native)	OCI / TNS	pgwire (compatible)
Failure mode	Often explicit	Enterprise support	Fail-closed contracts
Resource limits	Soft, advisory	Resource Manager	Hard, per-component
Recovery	WAL + checkpoint	ARIES-like	ARIES (Analysis → Redo → Undo)
Observability	Rich ecosystem	Enterprise tooling	Metrics + SQLSTATE + USDT
Platforms	All major OS	All major OS	Linux-only (by design)

Compared to modern alternatives

	CockroachDB	TiDB	DuckDB	AngaraBase
Workload profile	Distributed OLTP	HTAP MPP cluster	Embedded analytical	HTAP single-node
MVCC	HLC-based MVCC over Pebble	Percolator MVCC over TiKV	Single-writer MVCC	UNDO-log MVCC
VACUUM	RocksDB/Pebble compactions	GC over TiKV	Not applicable (in-process)	Not required
UPDATE/DELETE	Full	Full	Full (single-writer)	Full, lock-free per-row CAS
Wire protocol	pgwire	MySQL (pgwire experimental)	Native client / DBI	pgwire (compatible)
Deployment	Cluster (3+ nodes)	Cluster (TiKV + TiFlash)	Embedded library	Single-server (cluster on roadmap)
License	BSL → Apache 2.0	Apache 2.0	MIT	Apache 2.0

Roadmap & where we are not (yet)

Engineering honesty is a core value. We do not sell vaporware. Here is exactly what AngaraBase does not do today, and what is strictly on the roadmap:

HTAP is implemented, in production-preview: Columnar storage (AngaraColumn) with tiered L0/L1 layers and full DML (INSERT/UPDATE/DELETE/MERGE via delete-vectors and merge-on-read), SIMD aggregations. Automatic engine selection by the planner based on statistics is on the roadmap.
Distributed architecture is coming: We are currently a single-node system. Sharding, scale-out, and auto-failover are in active development (v0.7–v0.9+).
No multi-region active-active replication.
No full parity with the PostgreSQL extension ecosystem.
No Windows or macOS server — Linux-only by design.

Read our detailed RFCs and technical roadmap on the AngaraBase Tech Portal.

Early Access & Design Partners

Interested in testing AngaraBase in your stack? We are currently looking for design partners and early adopters who need predictable OLTP performance and want to co-engineer with us.

Reach out directly to the core team: partner@angarabase.com

Community

GitHub X Telegram Habr (engineering blog, RU)