0 · The lane — read this first
Centauri is not an Oracle replacement for general OLTP. It is a system of record: the immutable, bi-temporal, tamper-evident store for what happened, when, why, and how much to trust it — the job Oracle does with a stack of separately-licensed options (Flashback, Total Recall, Advanced Security, Database Vault, Advanced Compression, partitioning, auditing).
The honest framing for everything below: in this lane, Centauri delivers Oracle-grade capabilities — point-in-time reconstruction, tamper-evidence, encryption with crypto-erasure, row-level security, HA failover, compression, cold tiering — built into one free, zero-dependency binary. For high-concurrency multi-writer OLTP, a mature cost-based optimizer, RAC-scale clustering, and three decades of ecosystem, Oracle wins. Run Centauri beside your OLTP store, not instead of it.
1 · The atom: an immutable fact vs a mutable block
This single difference drives everything else.
Oracle
The atomic unit is a data block (typically 8 KB). Rows live inside blocks; an UPDATE rewrites the row in place within its block and records the prior image in an undo segment so other sessions still see the old value and the change can be rolled back. The current block is mutable; history is a side-effect kept (briefly) in undo.
Centauri
The atomic unit is an immutable fact appended to a log. An "update" appends a new fact that supersedes the old one; a "delete" appends a RETIRE marker. Nothing is ever rewritten in place, so every prior version already exists — history isn't a side-effect to retain, it's the substance of the database.
2 · The write / commit path
Both systems obey write-ahead logging — durability before visibility — but the log plays a different role.
Oracle: redo is a side-channel
- A DML statement changes a block in the buffer cache (in the SGA).
- The change is described as a redo entry in the log buffer; the before-image goes to undo.
- On
COMMIT, LGWR flushes redo to the online redo logs (commit = redo durable). An SCN (System Change Number) stamps the order. - DBWR writes dirty blocks to datafiles lazily, later, at a checkpoint. The datafiles are the database; redo exists to recover them.
Centauri: the log is the database
- A write is appended to the append-only log and linked into the SHA-256 hash chain.
- The bytes are made durable (
fsync) before any in-memory state changes — "write-then-apply." Optional group commit coalesces concurrent writes into one fsync. - Only then does apply() update the in-RAM indexes (current-fact pointers, vectors). Memory never gets ahead of disk.
- There are no separate datafiles to flush: the log is the source of truth; sealed segments and indexes are derived from it.
Oracle's SCN is a logical clock that totally orders changes. Centauri's equivalents are the hash-chain position (which both orders and proves each change) plus the two wall clocks every fact carries — valid time and transaction time.
3 · Storage & tiering
Oracle
Logical: tablespace → segment → extent → block. Physical: datafiles, often on ASM. Compression (Advanced Compression, or Hybrid Columnar Compression on Exadata) and partitioning are separately-licensed options. The optimizer skips data using indexes, partition pruning, and zone-map / storage-index features (Exadata).
Centauri
A hot append-only log seals into immutable segments that are flate-compressed (typically 5–10× on cold data) and carry uncompressed zone-map statistics + a Merkle root in their manifest — so the engine prunes and verifies a segment without decompressing it. Cold segments push to an S3-compatible tier (AWS/MinIO/R2/B2) over stdlib request-signing, fetched on demand, Merkle-verified, and LRU-cached. Compression, zone-map pruning and cold-tiering are built in and free.
The rough analogy: a Centauri segment plays the role of an Oracle datafile/extent — a sealed, scannable, prune-able unit — except it is immutable and content-addressed by a Merkle root, not mutated in place.
4 · Read consistency & time travel
Oracle: MVCC via undo
A query reads a consistent snapshot as of its start SCN by reconstructing blocks from undo. Flashback Query (AS OF SCN/TIMESTAMP) reads the past the same way — but only as far back as undo retention allows; run out and you hit ORA-01555 "snapshot too old." Long-term history needs Flashback Data Archive (formerly the extra-cost "Total Recall").
Centauri: time travel is native
Because nothing is overwritten, a point-in-time read is just a filter over facts already on disk — no undo to reconstruct, no retention to tune, no "snapshot too old." And it is bi-temporal: AS OF asks "what was true," AS KNOWN AT asks "what did we believe" — the audit superpower. History is unbounded by default.
-- Oracle SELECT * FROM orders AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '7' DAY); -- bounded by undo retention -- Centauri FACTS OF order:* AS OF '7 days ago' -- what was true, forever FACTS OF order:1 AS KNOWN AT '2026-03-01' -- what we believed then (no Oracle equivalent)
5 · Update, delete & the right to be forgotten
Oracle
UPDATE/DELETE mutate blocks in place (old image to undo). Truly removing data means the row is gone and only recoverable from backups/flashback within their window. Encryption at rest is TDE (Transparent Data Encryption, part of the Advanced Security option); fine-grained auditing and Database Vault are further options.
Centauri
An update is a superseding fact; a delete is a RETIRE marker — the history stays, auditable. For GDPR "erasure," crypto-erasure destroys the per-segment AES-256-GCM key so the payloads become permanently unreadable while the hash chain stays intact — you delete the data without breaking the proof of history. Encryption, masking and row-level security are built in, not options.
6 · Durability & crash recovery
Oracle: roll forward, then roll back
Instance recovery has two phases: roll forward — replay redo from the last checkpoint to reapply all changes (committed and not) to the datafiles; then roll back — use undo to reverse transactions that never committed. CKPT/DBWR advance the checkpoint to bound how much redo must be replayed.
Centauri: deterministic replay, no rollback phase
Recovery is a single deterministic replay of the committed log through apply(). There is no roll-back phase: write-then-apply means only durably-committed bytes were ever applied, and nothing was mutated in place, so there's nothing to undo. A periodic checkpoint means replay starts from the tail, not the beginning — recovery time stays bounded regardless of total history.
7 · Integrity & tamper-evidence
Oracle
Block checksums (DB_BLOCK_CHECKSUM) detect corruption (bit rot, bad I/O). For tamper-evidence — proving no one maliciously altered rows — Oracle added Blockchain Tables and Immutable Tables (21c+), a special table type you opt into.
Centauri
Tamper-evidence is the default for all data: every committed line folds the previous line's hash into its own SHA-256 hash chain, and each sealed segment publishes a Merkle root. Altering any past byte breaks every hash after it. verify recomputes the chain + roots on demand. It's not a special table type — it's how the whole log works.
8 · Concept-by-concept map
Oracle's data-management vocabulary, translated to Centauri.
| Oracle | What it does | Centauri equivalent |
|---|---|---|
| SGA buffer cache | In-memory cache of mutable blocks | In-RAM indexes (current fact per subject, vectors) + LRU decompressed-segment cache |
| Redo log + LGWR | Write-ahead log to recover datafiles | The append-only log itself — write-then-apply; the log is the database, not a recovery side-channel |
| SCN (System Change Number) | Logical clock ordering changes | Hash-chain position (orders and proves) + valid/transaction wall clocks per fact |
| Undo / rollback segments | Before-images for MVCC, rollback, flashback | Not needed — prior versions are already on the log; no undo retention, no ORA-01555 |
| DBWR + checkpoint (CKPT) | Flush dirty blocks; bound recovery | Periodic checkpoint (pointer/Merkle-validated) + auto-seal; replay starts from the tail |
| Tablespace / segment / extent / block | Storage hierarchy, mutable blocks | Hot log → immutable compressed segments with zone maps (datafile/extent analog; no block management) |
| ARCHIVELOG + RMAN + PITR | Archived redo, backup, point-in-time recovery | The log + segments are the archive; backup = copy files; PITR = AS KNOWN AT; log shipping built in |
| Flashback Query (AS OF) | Read the past via undo (bounded) | AS OF over full history, unbounded; plus AS KNOWN AT (belief time) Oracle has no equivalent for |
| Flashback Data Archive (Total Recall) | Long-term history (option) | The default design — complete bi-temporal history, free |
| Data Guard / Active Data Guard | Standby replicas for HA/DR (option) | Log shipping + durable CDC slots + lease-based automatic failover, free |
| GoldenGate / Streams | Change data capture to downstream systems (separate product) | Built-in CDC: /v1/changes with durable, resumable replication slots + acks, free |
| Oracle Sharding | Horizontal partitioning across databases (option) | serve -shards N — subject-hash sharding across independent logs, ~N× write throughput; honest limit: cross-shard queries are restricted |
| RAC (Real Application Clusters) | Shared-disk multi-node OLTP scale-out (option) | No equivalent — single-writer per log; sharding scales throughput across subjects; HA is active/standby, not RAC |
| Multitenant (CDB/PDB) | Pluggable databases (option beyond a limit) | Named environments per server with snapshot cloning, free |
| TDE (Advanced Security) | Transparent encryption at rest (option) | Per-segment AES-256-GCM + crypto-erasure, free |
| VPD / row-level security | Fine-grained access (EE feature) | Scoped tokens by subject prefix + field masking, free |
| Database Vault / FGA / Audit Vault | Separation of duties, auditing (options) | Enforced legal hold + a log where every fact is the audit, tamper-evident by default |
| ILM / retention policies + legal hold | Lifecycle management, retention, holds (options / Audit Vault) | Retention policies (dry-run by default, RETIRE-based — history kept) + enforced legal hold that blocks deletion of held subjects, free |
| Blockchain / Immutable Tables | Tamper-evident table type (21c+) | The entire log is hash-chained + Merkle-rooted — not a special table type |
| Advanced Compression / HCC | Compress data (option / Exadata) | Flate-compressed sealed segments, free |
| Cost-based optimizer (CBO) + stats | Plan selection over rich SQL | Partial — zone-map pruning + secondary index + EXPLAIN ANALYZE; no full CBO (honest gap) |
| SQL*Net / SQL | Wire protocol + full SQL | CeQL (native) + read-only SQL over the PostgreSQL wire protocol (psql/JDBC/BI) |
| AWR / ASH / Diagnostics Pack | Performance telemetry (packs) | Prometheus /metrics, health probes, structured logs, free |
| Select AI / OCI Generative AI | NL-to-SQL and LLM features, via Oracle Cloud services | Local-first AI in the binary: NL→CeQL, RAG ASK with citations, hybrid BM25+vector search, vision extraction — models run on your hardware via Ollama (auto-provisioned tiers up to GLM-4.7-Flash); the optional GLM-5.2 cloud boost is off by default and labeled |
9 · Process walkthroughs, side by side
9.1 Committing a change
Oracle
- Modify block in buffer cache
- Write redo to log buffer; before-image to undo
COMMIT→ LGWR flushes redo; SCN assigned- DBWR writes the dirty block to the datafile later, at a checkpoint
Centauri
- Append the fact; extend the hash chain
fsyncthe bytes (optionally group-committed)apply()updates in-RAM indexes — only after durability- Tail later seals into a compressed, Merkle-rooted segment
9.2 Reading last month's value
Oracle
SELECT … AS OF TIMESTAMP …- Reconstruct blocks from undo back to that SCN
- Fails with ORA-01555 if undo retention has lapsed; needs Flashback Data Archive for the long term
Centauri
FACTS OF … AS OF '1 month ago'- Filter facts already on disk — nothing to reconstruct
- Always available; add
AS KNOWN ATto also ask what was believed then
9.3 Deleting for GDPR / right to be forgotten
Oracle
DELETE(and purge from flashback/undo, backups, archives)- The audit trail of that data is lost along with it
- Encryption via TDE if the Advanced Security option is licensed
Centauri
RETIREthe subject (history retained, marked)- Destroy the segment's AES-256-GCM key → payloads unreadable forever
- The hash chain stays intact — you can still prove that the erasure happened
9.4 Surviving a crash & failing over
Oracle
- Instance recovery: roll forward redo, roll back uncommitted undo
- HA/DR via RAC (shared-disk cluster) and/or Data Guard standby — separately licensed
Centauri
- Replay the committed log from the last checkpoint — one deterministic pass, no roll-back phase
- HA via lease-based leader election: a replica auto-promotes when the primary's lease lapses (epoch-fenced), free
10 · Licensing & cost
The capabilities above — Flashback/Total Recall, Advanced Security/TDE, Database Vault, Advanced Compression, Partitioning, Active Data Guard, RAC, Multitenant beyond a limit, the Diagnostics/Tuning packs — are, on Oracle, typically separately-licensed Enterprise Edition options or management packs, charged per processor on top of the base license (exact entitlements vary by edition and version — check your contract).
In Centauri the equivalents — bi-temporal history, tamper-evidence, crypto-erasure, row-level security + masking, compression, S3 cold tiering, HA failover, metrics — are all in the single open binary: zero third-party dependencies, no per-core fee, no option matrix, no support contract required. That is the core "own your data" thesis: the engine is free and runs on infrastructure you control.
11 · Where Oracle still wins (honesty by policy)
- High-concurrency multi-writer OLTP. Centauri writes are single-writer per log (the hash chain is sequential by design). Oracle/RAC are built for thousands of concurrent writers and sub-millisecond transactions.
- Mature SQL + cost-based optimizer. Decades of SQL surface, a sophisticated CBO, PL/SQL, and tooling. Centauri's SQL is a read-only subset over the wire; CeQL is the full surface.
- Scale-out clustering. RAC's shared-disk, cache-fusion scale-out has no Centauri equivalent; Centauri scales reads/throughput by sharding and serves data beyond RAM, but it is not a clustered OLTP engine.
- Key management & security ecosystem. Centauri has no Vault/KMS integration — crypto-erasure keys are managed by the engine itself. Oracle's TDE integrates with external key stores (OKV/HSM).
- Ecosystem & hardening. Thirty-plus years of drivers, certifications, DBA expertise, and battle-testing at extreme scale.
So the recommendation is architectural, not partisan: keep Oracle (or free Postgres/SQLite) for transactional workloads; put Centauri beside it as the tamper-evident, bi-temporal, AI-queryable record of what happened and why — the part those engines don't do, without the option licenses.