Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

AngaraBase

A relational DBMS with PostgreSQL protocol and predictable behavior. Written in Rust. Current branch — 0.6.x.

Rust PostgreSQL pgwire MVCC · UNDO-log Soft Launch · v0.6.x

AngaraBase is designed for ERP/SaaS workloads, where predictability is more important than “magic”, and every behavior is defined by an explicit contract.

What this documentation covers

This covers what is already working in the code on the current branch. Roadmap features are marked separately. AngaraBase is a young project, and we prefer accuracy over marketing promises.


Getting Started

Choose your entry point based on your role:

Who you areWhere to go
Exploring the productWhat is AngaraBaseHigh-level Architecture
Want to try locallyQuickstart in 5 minutes
Application DeveloperSQL compatibilityData typesKnown issues
DBA / SREInstallationConfigurationBackup/RestoreOperations runbooks
Security engineerSecurity modelHardeningAudit
Contributor / ResearcherArchitecture overviewLayering and BoundariesGlossary
Reporting an issueSupport flow

Key Features

PostgreSQL Compatibility Without Surprises

  • Standard pgwire protocol: psql, JDBC, psycopg, node-postgres, pgx, Npgsql work just like with standard PostgreSQL.
  • Contractual SQL subset: what is supported is supported fully; what is not supported returns an explicit SQLSTATE (0A000 etc.) instead of a silent bypass.
  • Pinned compatibility tests (compat suite) as proof, rather than a “compatibility percentage”.

Read more: SQL compatibility overview.

Modern Engine: MVCC via UNDO-log, Not via Bloat

Unlike PostgreSQL, AngaraBase stores historical row versions in a separate UNDO-log (like Oracle/InnoDB), rather than in the table itself. As a result:

  • heap pages contain only current row versions → less bloat;
  • VACUUM in the traditional sense is not needed — old versions are cleaned up by the background AngaraGC according to a strict contract;
  • visibility for transactions is determined deterministically by snapshot.

Read more: Transactions and MVCC.

Pluggable Storage From Day One

  • Row-store (baseline) — for OLTP.
  • AngaraMemory — in-memory tables with three durability tiers (none / logged / snapshotted) and hard row-cap.
  • AngaraColumn — columnar storage for analytics (in roadmap; HTAP direction).

Storage engine is selected during CREATE TABLE ... WITH (storage='memory'|'row'|...).

Read more: Storage engine.

Cost-based Optimizer and Vectorized Execution

  • AngaraPlan — CBO with robust planning, resilient to estimation errors.
  • AngaraStat — statistics: HLL for NDV, equi-height histograms, MCV (reservoir sampling).
  • AngaraFlow — streaming execution (Volcano).
  • AngaraVector — vectorized path for scan/filter/project/join/aggregate; modes auto / force_vector / force_row. EXPLAIN explicitly shows VectorHashJoin, VectorAgg, etc.
  • AngaraParallel — partitioned parallel join, DOP-caps (ANGARABASE_PARALLEL_DOP_CAP_*).

Read more: Query processing.

Multi-layered Security With Explicit Contracts

Security is built into the core, not “bolted on” as an afterthought. Six layers of protection, each with its own contract:

  1. Transport and identity — TLS, SCRAM, cert authentication.
  2. RBAC — who is allowed at all.
  3. RLS v1 — which rows are visible and mutable.
  4. Break-glass — the only way to bypass RLS (even SUPERUSER doesn’t have it), always with a REASON, TTL, and audit.
  5. Audit chain — append-only, tamper-evident (SHA-256 chain).
  6. TDE — encryption of pages, WAL, and audit-sink; fail-closed without a key.

Read more: Security model.

Operations Built for Predictability

  • Per-database backup and restore (cold + online/PITR baseline).
  • Clear diagnostics: EXPLAIN/EXPLAIN ANALYZE, sys.* views (sys.identity, sys.health, sys.settings, sys.tables, sys.column_stats, angara_stat_activity, angara_stat_statements).
  • Structured logging, OpenTelemetry-style spans, USDT/eBPF probes.
  • Prometheus metrics: angara_* named subsystems are visible in logs, metrics, and EXPLAIN.
  • Native RPM/DEB packages, init-first service start fence, systemd units.

Read more: Operations runbooks.

Project Principles (Explicit Stance)

PrincipleWhat it means
Restrictive by defaultStrict checks and authentication by default. Bypasses — only via explicit flag
Contract-firstEvery feature has an explicit contract: what is supported, what SQLSTATE on failure, what invariants
Fail-closedWhen uncertain — an explicit error, not “it will work somehow”
Evidence-firstCorrectness is proven by test artifacts, not marketing
PostgreSQL-friendlyNo custom clients: all compatibility is via pgwire
Minimum dependenciesFewer runtime dependencies → smaller supply-chain attack surface

Full declaration: Project principles.


Documentation Sections

Tutorials

Concepts (Explanation)

SQL Reference

  • Compatibility Overview — policy, SQLSTATE codes, vector execution
  • Data Types — supported types, casting, NULL
  • DDL — CREATE/ALTER/DROP, indexes, constraints
  • DML — INSERT, UPDATE, DELETE, mutation policies
  • Queries — CTE, JOIN, aggregates, ORDER BY
  • Partitioning — RANGE/LIST partitioning, routing, pruning

Security (How-to)

Operations (How-to)

Operator deep-dives — runbooks (Reference)

Architecture (Reference)

Reference

Changelog


Community and Contribution

We welcome community contributors:

  • Found a bug or regression? Gather artifacts according to the Support flow and open an issue.
  • Want to change behavior? Propose an RFC via the project’s development process (internal loop).
  • Want to help with documentation? AngaraBook is documentation-as-code in the same repository. Formatting rules: see the internal WRITING_RULES.md next to the book.
  • Want to track development? Follow the changelog and release notes.

About the Documentation

AngaraBook is built on the principles of Diátaxis:

  • Tutorials — learning through action, for new users.
  • How-to guides (Security / Operations) — recipes for specific tasks.
  • Reference (SQL / Architecture) — exact description of behavior.
  • Explanation (Concepts) — why things are designed the way they are.

Quality Guarantees:

  • Documentation is code: edited in the same repository, passes the same CI as the engine.
  • Any claimed SQL/ops behavior is verified by pinned tests or explicitly marked as a roadmap feature.
  • Anti-drift: command versions, configuration keys, and SQLSTATE codes are checked automatically.
  • Public build passes a security gate: internal processes and confidential links do not make it into the public portal.

If you notice a discrepancy between the documentation and actual behavior — this is a documentation bug; please report it.


AngaraBase v0.6.x · Linux x86_64/aarch64 · glibc >= 2.28