One database instead of Postgres + Redis + a queue + a cron job
Datacenter
Joined March 2024
- Tweets134
- Following8
- Followers697
- Likes196
Ten seconds ago, I compared P99 with P100. OUTSCH
Apply(volume)@op263
total=89.4ms calls=410
p99=915us
p100=29.7ms
Thank you for this
Kudos to #instantdb for handling it prompt and swiftly. The underlying issue exists for decades.
It is time for it to change, now.
reifydb.com/manifesto
Tell me why I am wrong, by clicking the button at the bottom.
reifydb.com/manifesto
The button at the bottom goes straight to my inbox.
Use it.
______________________
| Deploys every day. |
| Green every time. |
|______________________|
+----------+
| [][][] o |
+----------+
| [][][] o |
+----------+
| [][][] o |
+----------+
|| ||
#database
The Cron Job You Deleted
Refresh jobs exist because the database could not keep a number current. Incremental views remove the job.
#buildinpublic
reifydb.com/blog/the-cron-jo…
ReifyDB retweeted
Only dudes at the @ns coworking space will understand.
Hint: it’s not for recycling.
Gotta do what you gotta do when you’re pushing raptor[dot]trade for @colosseum.
Building a database business right after reading this is either conviction or brain damage 😂
strong thesis:
the database problem is not only architecture.
It is incentives, margins, switching costs, and who captures the value.
That is exactly why the stack needs rethinking.
#reifydb #database
THE BROKEN ECONOMICS OF DATABASES (or, why all databases are doomed to suck)
I cover a very good article by @almoggavra where he explains:
• why infra companies can have absurdly-high gross margins yet still risk bankruptcy
• why moats & unfair advantages (distribution, production) matter
• why competition kills profits
• why companies result to shady tactics to safeguard their revenue
• why software cannot be distinguished from the business (& financials) behind it
• why price isn't everything behind software (hint: switching costs)
• why S3 can promise to solve all of these issues
all that and more in the latest video 👇
ReifyDB can now run tests with namespace filtering.
That means you can define tests across different parts of your database, then execute only the ones you care about.
CREATE TEST ns_a::test_one { ... }
CREATE TEST ns_a::test_two { ... }
CREATE TEST ns_b::test_three { ... }
RUN TESTS ns_a
Result:
ns_a::test_one ✅
ns_a::test_two ✅
ns_b::test_three is excluded
I like this because tests start behaving more like real database objects.
Not just “run all tests”.
Not just an external harness.
But targeted, queryable test execution inside the database itself.
Feels especially useful for larger schemas, multi-tenant setups, and staged rollouts.
#reifydb #database #rustlang #buildinpublic
What if integration tests were a database primitive?
That’s something I am prototyping at #reifydb
CREATE TEST test::insert {
INSERT test::users [{ id: 99, name: "Ghost" }];
FROM test::users
| FILTER id == 99
| ASSERT { name == "Ghost" };
};
Not a wrapper.
Not a framework.
Not an external runner.
A native test object inside the #database itself, invoked before a schema change, making stored procedures easily testable.
I think this is a missing building block for databases built around live application state.
Yesterday: #LunarEclipse.
Today: watching teams do "data eclipses" with ETL pipelines. 😅
ReifyDB’s goal is boringly simple: keep the state current so your app never goes dark.
Computer Science 101: "Don't build your own database!!! Ever!!"
Translation: accept slow queries, bolt on caches, babysit pipelines, and call it "architecture".
I rejected that.
Databases shouldn't fight developers.
They should model live application state, stay correct as data changes, and be predictable under pressure.
So I am building ReifyDB.
Sometimes the real 10x move isn't scaling your stack, it is questioning why the stack looks that way at all.
