Event Sourcing: Why LuperIQ CMS Does Not Use a Traditional Database

The Problem with Traditional Databases

Most CMS platforms store data in a relational database. When you edit a page, the old version is overwritten. Want to know what changed last Tuesday? Hope you had backups. Need to audit who modified a customer record? That requires a separate audit logging system.

Event Sourcing: A Different Approach

LuperIQ CMS stores every change as an immutable event in an append-only write-ahead log. Edit a page? That is an event. Create a booking? Event. Update a price? Event. Nothing is ever overwritten or deleted.

The current state of your site is computed by replaying these events. Need to see what your site looked like last week? Replay events up to that point. Need a full audit trail? It is built into the architecture — every event includes a timestamp, author, and BLAKE3 cryptographic hash chained to the previous event.

What This Means for Your Business

Instant backup and restore. Your entire site state lives in a single binary file. Back it up by copying one file. Restore by copying it back.

Complete audit trail. Every change to every piece of data — pages, products, bookings, invoices, customer records — is permanently recorded with who made the change and when.

No database server. No MySQL, no PostgreSQL, no database tuning, no connection pool management. The CMS binary reads and writes directly to the event log file. One less service to manage, monitor, and secure.

Blazing-fast reads. State is rebuilt from a snapshot (binary checkpoint) on startup, then kept in memory. Reads are direct memory access — no SQL query overhead.

Built on Rust

The event sourcing engine (luperiq-forge) is written in Rust with memory safety guarantees. The append-only log uses synchronous writes with fsync for durability — your data survives power outages and crashes.