3 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 16d 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 16d ago> What if you just ran FoundationDB instead? Would that let you do collaboration blog-posts with another VC-funded startup though?
- kjs3 16d agoPriorities...won't people think of the really important priorities. :-)
- ddorian43 16d 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 16d 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 16d 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 16d 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 16d 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.