Application State Database
ReifyDB stores, mutates, and derives live application state under one transactional model. State lives in memory for low latency, is persisted asynchronously for durability, and is queried directly by your frontends: ReifyDB is built to replace the backend layer, not to sit behind one.
The problem it replaces
Most applications fragment their state across systems: a database for persistence, a cache for speed, and background workers that keep derived data fresh. Each seam adds failure modes - cache invalidation bugs, stale read models, polling jobs that recompute what a write already knew.
ReifyDB collapses those layers into one engine: tables hold authoritative state, and views derive from them incrementally as data changes. Run the snippets on this page in order. First, a table and two views that aggregate it - one transactional, one deferred:
Now write to the table. There is no second system to notify and no refresh job to schedule:
The transactional view was maintained by the write itself. Reading it costs a lookup, not a recomputation:
Transactional or deferred
The two views above are kept fresh in different ways, and the difference is the main decision you make per view. A transactional view is maintained inside the writing transaction: when the commit returns, the view is already correct, at the cost of doing that work on the write path. A deferred view is maintained asynchronously from the change stream after the commit: writes stay cheap, and the view catches up moments later - it is eventually consistent.
Use transactional views for derived state that reads must never see stale - balances, inventory, anything an invariant depends on. Use deferred views when a moment of lag is fine and write latency matters - dashboards, counters, feeds. See Views for the full comparison.
State first, queries second
In ReifyDB, state is the primary concept and queries are secondary. Tables represent authoritative state; views represent derived state, not reports - you choose per view how fresh it must be.
Alongside tables and views, the engine has specialized state shapes - ring buffers, series, dictionaries - so state that would otherwise live in Redis or a custom service participates in the same transactions. A ring buffer, for example, is bounded state with eviction built in:
Four rows were inserted into a buffer with capacity three; the oldest was evicted. No cleanup job required.
In-memory, asynchronously durable
All state changes go through transactions, and a committed change is visible immediately - but the commit does not wait for disk. Persistence happens off the hot path with bounded latency, and recovery rebuilds state deterministically from durable storage.
That trade is deliberate. Application state is read and written on every request, so ReifyDB prioritizes predictable low latency over synchronous durability on each individual write. See Durability & Storage for what this means for crash recovery.
What ReifyDB is not
ReifyDB manages the live, mutable state your application reasons about on every request. It is not a BI warehouse and not an analytics engine for ad-hoc queries over cold historical data. Those workloads have different trade-offs and belong in different systems.
Where to go next
- --Quickstart - build a live view and watch it maintain itself
- --RQL in Five Minutes - the pipeline query language used on this page
- --Data Model - namespaces, tables, and the specialized state shapes
- --Views - transactional vs deferred views in depth
- --Transactions - the model every state change goes through