No cac

CREATE NAMESPACE IF NOT EXISTS tp;
CREATE TABLE IF NOT EXISTS tp::users { id: int4, name: utf8 };
CREATE TEST PROCEDURE tp::seed_users AS {
  INSERT tp::users [{ id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }];
};
CREATE TEST tp::can_query {
  CALL tp::seed_users();
  FROM tp::users | ASSERT { id > 0 };
};
CREATE TEST tp::can_filter {
  CALL tp::seed_users();
  FROM tp::users | FILTER name == 'Alice' | ASSERT { id == 1 };
};
RUN TESTS tp | map { name, namespace, outcome, message };

Explore all examples →Take the tour →Open playground →

Your state, your logic, your derived views, all in one transactional flow. No caches to invalidate. No cron to babysit. No drift to debug.

Read the Docs View on GitHub

How It Works

Why ReifyDB

You should not need four systems to manage state that lives in one place. ReifyDB gives you transactions, incremental views, and programmable logic in a single engine.

Write state transactionally

Full ACID guarantees. If something goes wrong, it rolls back. No partial writes.

Validate and apply logic

Business rules run inside the same transaction, right next to the data.

Stay fresh automatically

Derived views update the moment the transaction commits. No polling, no stale data.

ACID core for live state

Your state stays consistent, even under contention. Serializable transactions with real rollback, not the best-effort scripts you are used to patching together.

Incremental derived views

Your views update the moment your data changes. No cron job to schedule, no polling loop to tune, no dashboard that is quietly three minutes behind.

Programmable transitions

Your validation and business rules run inside the transaction, right next to the data. Fewer round trips, fewer places for things to go wrong.

Native state primitives

Tables, counters, ring buffers, histograms, and views all live in one transactional core. Embed it in your app or run it as a server.

Book a call Read the docs

Use Cases

Built for Live Application State

If your application reads it, writes it, and reasons about it on every request, that is the state ReifyDB was built for.

Trading & Financial State

Positions, balances, order state. One bad write here can cost real money. ReifyDB makes sure that does not happen.

Game & Simulation State

Player state, world state, simulation ticks. Everything stays consistent even when thousands of updates hit at once.

Try Demo →

Workflow & Process State

Multi-step workflows, task queues, process coordination. No more duct-taping Redis, Postgres, and a cron job together.

Counters, Queues & Buffers

Counters, ring buffers, histograms, rate limiters. Built in, transactional, and ready to use. No external dependencies.

Replaces

What ReifyDB Replaces

You have probably duct-taped three or four systems together just to manage state. Here is what you can stop maintaining.

PostgreSQL + Redis→Single Transactional Store

You know that moment when your cache says one thing and your database says another? That goes away. One store, one source of truth.

Batch Materialized Views→Incremental Derived State

Your views update when your data changes, not whenever a cron job gets around to it. No polling, no refresh buttons, no stale numbers.

Scattered Service Logic→Programmable Transitions

Stop scattering your state logic across microservices, workers, and cron jobs. Put it next to the data where it belongs.

Redis + Kafka + Custom Code→Native State Primitives

Counters, queues, ring buffers, histograms. You do not need three systems and a pile of glue code. One engine, full transactional guarantees.

FAQ

Frequently Asked Questions

Honest answers to the questions engineers actually ask

ReifyDB is a database for application state. It helps you understand, mutate, and derive live application state under a single transactional model. State is kept in memory for low latency, persisted asynchronously for durability, and extended with application-defined logic that runs next to the data.

PostgreSQL is disk-first: durable and query-rich, but slow for real-time state. Redis is memory-first: fast, but transactions lack rollbacks and there is no derived state. ReifyDB is designed around reasoning about state - with full ACID transactions, plus incremental materialized views and programmable logic that runs inside the database.

No. ReifyDB is in active development. APIs and guarantees may change. I recommend using it for experimentation and development, but not for production workloads yet.

View All FAQs →

Still have questions? Ask on Discord →

Want to see if ReifyDB fits your workload?

Read the docs, try the examples, or book a call. We will be honest about whether ReifyDB is the right fit.

No cac█