One database instead of Postgres + Redis + a queue + a cron job.
Writes, business rules, and derived views commit in one transaction, inside the database, as the user who asked. Nothing to invalidate. Nothing to babysit.
cargo add reifydbYou have built this.
A database. Then Redis, because it was not fast enough. Then a cron job, because a dashboard needed a total. Then a queue, because a rule had to run on write. All of it connecting as one account, with one password.
You did not architect that. You accumulated it.
Every box is an apology.
Each system exists because the database could not do one specific thing. Here is what each one stands 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.
Tables hold the rows. Views hold the derived numbers, and the write keeps them current. Rules run inside the transaction. Counters, queues and histograms are built in. And clients authenticate as themselves, so policies decide per user what may be read and written.
Alice places an order. First on today's stack, then on ReifyDB.
The network sets your speed limit.
Drag the sliders. Every statement in a round-trip architecture pays for the network again. ReifyDB pays once, for the whole transaction.
one round trip per statement, 18 of them
90 ms
spent on the network, per transaction
one round trip, the whole transaction
5 ms
spent on the network, per transaction
18× the network time, before the database has done any work.
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.
Read the docs, run the examples in the playground, and see how it fits your workload.