Object Storage Is All You Need: How One Startup Ditched Postgres
Ampbase founder JP explains how his company runs its entire control plane on Tigris object storage with no database underneath. Using strong read-after-write consistency and conditional writes as primitives, they hand-built unique constraints, transactions, indices, and history tables. Isolation comes from per-customer buckets and scoped credentials, so there's no WHERE org_id clause to forget. The trade-off: O(1) access only to questions you anticipated in advance.
History can't be lost by a careless UPDATE, because there is no UPDATE.
- dullcrisp
This article doesn’t present much motivation for why you would do this.
To me it reads a bit like, how we built our office without desks: it turns out if you stack two chairs on top of each other, you can balance your laptop on the top and you’ll also have a shelf on the bottom for your things.
- ryanbrunner
Articles like this remind me of that Innovation Tokens article.
Your time and attention is precious as a developer. I'm absolutely sure it's possible to implement uniqueness constraints, transactions, indices, and history yourself, but is that really the most valuable use of your time? There's probably not a need for you to have a unique solution, so you're quite literally just re-inventing something someone already had for not a lot of benefit.
Wouldn't your time be better spent actually solving the problems that whatever you're building is supposed to solve?
- arpinum
This is frustrating to read. Tigres is built on FoundationDB, but doesn't expose all FoundationDB operations like transactions, range reads, and get mapped range. They go through all sorts of complications to handle these issues, including a database for caching (and they don't consider thundering herd problems).
What if you just ran FoundationDB instead?
- agentultra
> In practice, when you reach for a database engine you're actually reaching for four basic features: unique constraints, transactions, indices, and history tables.
That might be a very specific assumption. What about serializability? Replication? Materialized views? Procedures? Locking? Access control?
It’s cool to experiment and try new approaches. Neat one here.
Could still end up moving to Postgres.
- i2km
Along with putting estimated reading times (21 minutes in this case) can authors please start putting estimated writing times?
Did it take 10 seconds of prompting? Or hours of thought, trial error and revision? Especially when asking people to read for 20+ minutes...