The database that runs your backend logic.

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:

create namespace cpt;
create table cpt::orders { id: int4, region: utf8, total: float8 };
create transactional view cpt::revenue_by_region { region: utf8, revenue: float8 } as {
  from cpt::orders
  aggregate { revenue: math::sum(total) } by { region }
};
create deferred view cpt::order_count { orders: int8 } as {
  from cpt::orders
  aggregate { orders: math::count(id) } by {}
}

Now write to the table. There is no second system to notify and no refresh job to schedule:

insert cpt::orders [
  { id: 1, region: "North", total: 120.0 },
  { id: 2, region: "South", total: 80.0 },
  { id: 3, region: "North", total: 45.5 }
]

The transactional view was maintained by the write itself. Reading it costs a lookup, not a recomputation:

from cpt::revenue_by_region
sort { region: asc }

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.

from cpt::order_count

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:

create namespace cpt_rb;
create ringbuffer cpt_rb::recent_logins {
  user_id: int4,
  at: utf8
} with { capacity: 3 };
insert cpt_rb::recent_logins [
  { user_id: 1, at: "09:00" },
  { user_id: 2, at: "09:05" },
  { user_id: 3, at: "09:12" },
  { user_id: 4, at: "09:20" }
];
from cpt_rb::recent_logins

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