ovaistariq

Tigris 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.

Yes a good object storage service provider would. It all depends on what you are optimizing for. If you are only optimizing for cost then there are several cheap options that probably don't make sense for hot or warm storage. But if you care about availability, consistency, and latency guarantees then there are different service providers available.

There is no way to reliably prove that bytes have made their way to the disk without issuing fsync. Thus, without it you cannot guarantee that writes ACKed to the client survive any failure afterwards

This is very cool.

Spec and features are intertwined. Customers who switch away from AWS S3 still want to use the same SDKs, libraries, etc that support S3 API. They don't want to rewrite their applications to use a new API. So then is it feature coverage or spec coverage?

The API has sort of become a standard. There are many providers providing S3 API-compatible storage.

or Tigris

TLDR: EFS as a eventually consistent cache in front of S3.

The critical part of Dropbox is not just the storage layer but a combination of their client and server. Even small things like how do you handle conflicting writes to the same file from multiple threads, matter a great deal for data consistency and durability.

That works. Please do reach out. I love nerding out and would be happy to help in anyway I can.

Ovais - co-founder of Tigris here.

This is very cool. I have been thinking about embedded databases running on Tigris. Specially from an agent perspective, agents can suspend and continue their sessions. Would love to collaborate.