2 ms·
This is frustrating to read. Tigres is built on FoundationDB, but doesn't expose all FoundationDB operations like transactions, range reads, and get mapped rang
by arpinum 2mo ago
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?
- embedding-shape 2mo ago> What if you just ran FoundationDB instead? Would that let you do collaboration blog-posts with another VC-funded startup though?
- kjs3 2mo agoPriorities...won't people think of the really important priorities. :-)
- ddorian43 2mo agoFoundationDB 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)
- arpinum 2mo ago> the database is the last thing you want to re-invent good news, FoundationDB is already invented, and just slightly more tested than others on the market.
- xena 2mo agoI've occasionally pitched the idea of exposing transactions for object storage based on bucket forking. I think the idea is finally starting to land, but it's a really "out there" usecase that is likely hard to conceptualize until it's usable in some form.
- ovaistariq 2mo agoTigris founder here. So part of the reason we do not expose other database like APIs is because we are a S3-compatible store, so anything we expose has to fit into the S3 API semantics. In our current design we use FDB as our metadata store which is the sort of workload it is really good at.
- arpinum 2mo agoMy complaint is about your customer's choices, not yours. The customer solved their problem, but they also created the problem in the first place by building on an abstraction that hides capabilities they need.