Architecture

Litebase rethinks how databases handle transactions, storage, and query execution by making the transaction log a first-class primitive. Instead of treating logs as an internal mechanism, Litebase exposes the transaction log as the single source of truth, allowing applications to leverage immutable, append-only data storage for both structured queries and real-time event streaming.

By separating storage from compute, Litebase ensures efficient ingestion, retrieval, and processing of large-scale data without the limitations of traditional databases. Using NVMe SSD caching, asynchronous indexing, and object storage, Litebase achieves high-throughput, low-latency access to both structured and unstructured data.

But wait—how does Litebase achieve strong consistency, efficient queries, and real-time processing without the bottlenecks of conventional databases?

We rethink three fundamental principles:

• We separate storage from compute.
• We separate indexing from transaction commits.
• We treat the transaction log as the single source of truth.

Separation of Storage and Compute

Separating storage from compute is what makes modern data processing systems scale effortlessly. Instead of tightly coupling query execution to disk-based storage, Litebase stores all persistent data in object storage, while compute nodes only handle query execution and caching. This separation allows compute resources to scale dynamically in response to workload changes, without the overhead of rebalancing storage.

With this architecture, Litebase benefits from:

• Infinite storage scalability—Object storage serves as the authoritative data store, eliminating the complexity of disk replication.
• Dynamic scaling—Compute nodes can be added or removed without affecting data integrity or availability.
• Fast failover—Any compute node can process any request, ensuring no single point of failure.

Instead of relying on expensive disk replication, Litebase leverages NVMe SSDs and memory caching to keep frequently accessed data fast, while pulling cold data from object storage on demand.

Transaction Log as the Source of Truth

At the heart of Litebase is its transaction log, an immutable sequence of events that records every database change in strict order. Instead of immediately updating indexes or storage tables, all writes are first appended to the log, ensuring strong consistency and durability before any further processing.

This design brings several advantages:

• Strictly ordered writes—Every transaction is logged in sequence, making state reconstruction simple and deterministic.
• Instant durability—As soon as a write is committed to the log, it is permanently stored.
• Time-travel queries—Any historical state can be reconstructed by replaying the log, eliminating the need for complex snapshot mechanisms.

Litebase does not rely on distributed consensus for storage—instead, all writes are append-only, making it highly scalable and efficient under heavy concurrency.

Cold vs. Warm Reads: Optimizing Query Execution

Query performance in Litebase is optimized using a two-tiered retrieval system:

1. NVMe SSD Cache: Queries first check for results in the fast local cache for sub-millisecond response times.
2. Object Storage: If the data isn’t cached, Litebase fetches it from object storage, which adds an initial cold query latency of ~500ms (p90) for 1M records. However, once retrieved, subsequent requests benefit from cache locality, reducing query latency to ~27ms (p50) for the same dataset.

To optimize performance, Litebase dynamically routes queries to compute nodes with cached data, reducing redundant reads from object storage. For latency-sensitive applications, pre-flight queries can pre-warm the cache before user-facing interactions.

Asynchronous Indexing for High-Throughput Writes

Unlike traditional databases that block writes until indexes are updated, Litebase optimizes performance by processing writes in two stages:

1. Log Append (Commit Phase): Transactions are first written to the transaction log, ensuring immediate durability and consistency.
2. Asynchronous Indexing: New data is then indexed in the background, allowing future queries to retrieve it efficiently.

This design means that even before indexing is complete, new data remains queryable—Litebase simply scans recent log entries if necessary. This ensures:

• Uninterrupted write throughput—No write stalls due to indexing overhead.
• Consistently fast queries—Indexes are built asynchronously without impacting transaction performance.
• No unindexed data loss—Even if indexing lags behind, all data remains available.

Event-Driven Processing & Real-Time Streaming

Since every write is captured in the transaction log, Litebase enables real-time event processing without requiring a separate event streaming system. Applications can consume the log as a continuous data stream, reacting to changes instantly.

This makes Litebase ideal for:

• AI inference caching—Triggering machine learning pipelines based on real-time data changes.
• Event-driven analytics—Processing new records as they arrive instead of running periodic batch jobs.
• Streaming ETL pipelines—Ingesting and transforming data in real-time, rather than relying on scheduled updates.

Instead of polling the database for changes, applications subscribe to the log, ensuring that updates propagate as soon as they happen.

Cost Efficiency: Balancing Performance and Storage Costs

Litebase minimizes operational costs by storing all persistent data in object storage while using NVMe SSDs for caching. This architecture:

• Eliminates the need for replicated disks, significantly reducing storage costs.
• Caches only frequently accessed data, reducing the need for expensive all-in-memory solutions.
• Scales compute and storage independently, optimizing infrastructure utilization.

However, this also means that cold queries (reading from object storage) are slower than warm queries. Applications needing ultra-low latency should pre-warm critical datasets in cache for optimal performance.