One database instead of Postgres + Redis + a queue + a cron job.
Your writes, your rules, and your derived views run in one transaction, inside the database, as the user who asked. No caches to invalidate. No cron to babysit. No drift to debug.
You have built this.
You have a database. Then the product needed to be fast, so the hot rows got copied into Redis. Then a dashboard needed a total, so a cron job started recomputing it. Then a rule had to run when an order changed, so it moved into a worker behind a queue. And all of it connects to the database as one account, with one password.
You did not architect that. You accumulated it.
Today+---------------+ | POSTGRES | +---------------+ ~ glue ~ +---------------+ | REDIS | +---------------+ ~ glue ~ +---------------+ | CRON | +---------------+ ~ glue ~ +---------------+ | QUEUE | +---------------+ ~ glue ~ +---------------+ | WORKERS | +---------------+ five systems, one state | v With ReifyDB+---------------+ | REIFYDB | | | | tables | | views | | transitions | | primitives | +---------------+ one system, one transaction
Every box is an apology.
Each system in that stack exists because the database could not do one specific thing. Here is what each one is standing in for, and what takes its place.
The database could not serve these rows fast enough, so now there are two of them. One is right.
The database could not keep a derived number current, so it is recomputed on a timer. Between runs it is wrong, and it looks fresh.
The database could not run your logic when the data changed, so the logic runs afterwards, elsewhere, and hopes the data has not moved.
The database could not tell your users apart, so everything connects as one privileged account and the code in front of it decides who may do what. Every rule lives twice, one connection can do anything, and queries get built from user input on the way through.
None of the above knows about the others, so you wrote the code that does. It is the most fragile code you own, and it ships no feature.
Same feature. Two stacks.
ReifyDB is one database for that state. Tables hold the rows. Views hold the derived numbers, and the write keeps them current. Rules run inside the transaction, as procedures and handlers you version and test. Counters, queues, ring buffers, and histograms are built in. And it knows who is asking: clients authenticate as themselves, and policies decide, per user, what may be read and written.
Alice places an order. First on today's stack, then on ReifyDB.
- redisdrop cached balance
- queueworker: totals
- cronrevenue, later
- policy
- alice may place orders
- procedure
- check balance, insert, debit
- view
- revenue, updated by the same write
The Network Sets Your Speed Limit
Every database has a ceiling set by the slowest step that cannot run in parallel. Drag the sliders and watch a round-trip architecture hit its wall, while ReifyDB does not.
( [ App ] → [ DB ] → [ App ] ) × N, one round trip per statement.
2.0k TPS
Ceiling, engine capped at 100.0k TPS
[ App ] → [ N statements, one ACID transaction ] → [ ReifyDB ], no round trips.
100.0k TPS
Actual, unaffected by round trips or contention
The network is the hard limit. ReifyDB eliminates round trips from the hot path.
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.
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.
FAQ
Frequently Asked Questions
Honest answers to the questions engineers actually ask
Still have questions? Ask on Discord →
One database instead of Postgres + Redis + a queue + a cron job.
Version 0.9. Not production ready, and every page says so. Read the docs, run the examples in the playground, and see if it fits your workload.