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.
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).
Also, the database is the last thing you want to re-invent unless your business is explicitly building a db (even then it's best to re-use a db like all the postgresql forks that have existed)
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?
Absolutely no mention of Iceberg or Delta Lake, which have had many of the same properties for years. I wonder if they are aware of them, or otherwise why they invented something new.
I generally don't read low-quality AI slop though, so its possible I missed an explanation that didn't contain those key words.
Author here. Ampbase is an OpAMP control plane for agent fleets, and this is how it runs without a database: conditional writes for uniqueness and compare-and-swap, one bucket per customer so isolation isn't a WHERE clause somebody has to remember, ULID keys so history is a prefix list.
Two things the post doesn't cover and I'm happy to get into. What closing the cross-region lost update actually took: annotating the RPCs that depend on a compare-and-swap and replaying those to a single region, with a client-side guard. And the read amplification, which we have a plan for but waiting on a clear signal for when it’s needed.
Cross-posted with thanks to the Tigris folks; the original is at ampbase.io.
> In practice, when you reach for a database engine you're actually reaching for four basic features: unique constraints, transactions, indices, and history tables. In order to use Tigris' global object storage as a database, we had to implement all of these primitives ourselves.
Not sure why the "without a database" is or isn't so important, why is it mentioned so often and why the article flip-flopping between "we don't have a DB" and "we're effectively building our own DB"?
> [..] so isolation isn't a WHERE clause somebody has to remember, [..] Two things the post doesn't cover and I'm happy to get into. What closing the cross-region lost update actually took: [..]
Set of my Claude alarm bell, and lo-and-behold, Pangram judges this comment to be 100% AI-generated, albeit with limited confidence.
People who grew up with assembly language or locking primitives are fairly likely to use compare-and-swap because it's literally the commonly understood term for it.
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.
> Protobuf field names are forever
If you only have binary encoded protos to worry about (which is typical) then you can rename fields.
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?
> What if you just ran FoundationDB instead?
Would that let you do collaboration blog-posts with another VC-funded startup though?
FoundationDB is only as metadata store.
Also, the database is the last thing you want to re-invent unless your business is explicitly building a db (even then it's best to re-use a db like all the postgresql forks that have existed)
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?
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...
Absolutely no mention of Iceberg or Delta Lake, which have had many of the same properties for years. I wonder if they are aware of them, or otherwise why they invented something new.
I generally don't read low-quality AI slop though, so its possible I missed an explanation that didn't contain those key words.
Author here. Ampbase is an OpAMP control plane for agent fleets, and this is how it runs without a database: conditional writes for uniqueness and compare-and-swap, one bucket per customer so isolation isn't a WHERE clause somebody has to remember, ULID keys so history is a prefix list.
Two things the post doesn't cover and I'm happy to get into. What closing the cross-region lost update actually took: annotating the RPCs that depend on a compare-and-swap and replaying those to a single region, with a client-side guard. And the read amplification, which we have a plan for but waiting on a clear signal for when it’s needed.
Cross-posted with thanks to the Tigris folks; the original is at ampbase.io.
> and this is how it runs without a database
From the article:
> In practice, when you reach for a database engine you're actually reaching for four basic features: unique constraints, transactions, indices, and history tables. In order to use Tigris' global object storage as a database, we had to implement all of these primitives ourselves.
Not sure why the "without a database" is or isn't so important, why is it mentioned so often and why the article flip-flopping between "we don't have a DB" and "we're effectively building our own DB"?
> [..] so isolation isn't a WHERE clause somebody has to remember, [..] Two things the post doesn't cover and I'm happy to get into. What closing the cross-region lost update actually took: [..]
Set of my Claude alarm bell, and lo-and-behold, Pangram judges this comment to be 100% AI-generated, albeit with limited confidence.
There's even a load-bearing in there as well
real people don't write "compare-and-swap" ... or "lo-and-behold" for that matter.
edit. Clearly the joke about "lo-and-behold" didn't land well with the bots...
People who grew up with assembly language or locking primitives are fairly likely to use compare-and-swap because it's literally the commonly understood term for it.
https://en.wikipedia.org/wiki/Compare-and-swap
Compare-and-swap is a hardware instruction, and beyond that a desirable pattern for dealing with concurrent writes.
CMPXCHG
https://www.felixcloutier.com/x86/cmpxchg
https://lwn.net/Articles/847973/