ovaistariq

We wrote a bit about using FoundationDB at Tigris: https://www.tigrisdata.com/blog/fdb-krea-talk/

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.

Check out Tigris: https://www.tigrisdata.com/

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.

Add Tigris to the list as well please.

We maintain a page that shows our compatibility with S3 API. It's at https://www.tigrisdata.com/docs/api/s3/. The test runner is open source at https://github.com/tigrisdata-community/s3-api-compat-tests

or Tigris

Potential of startup for hosted object storage? I think Tigris (https://www.tigrisdata.com/docs/) will work pretty well with Render.

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.

Well we have made small objects work well on Tigris (https://www.tigrisdata.com/). And we have several use cases of folks using it as KV store. Funny that you mention FoundationDB, we use that for our metadata storage.

Yeah, there are no quotas in Tigris. Agents can create as many as needed:)

It would be great to pair it up with Tigris as well

There is https://www.tigrisdata.com/

What other AWS services do you depend on?

Or consider Tigris object storage service.

I don’t see much benefit from the disclosure alone. Ultimately, this is code that needs to be reviewed. There is going to continue to be more and more AI assisted code generation, to the point where we see the same level of adoption of these tools as "Autocomplete". Why not solve this through tooling? I have had great effect with tools like Greptile, Cursor's BugBot and Claude Code.

How AI is transforming software development from autocomplete to autonomous agents, and what this means for the future of coding.

The takeaway is that if your workload involves small objects (which we see with training workloads for our customers), and you are using the neoclouds, then Tigris will offer better latency and throughput.

Author of the blog post here.

The test is relevant for users running workloads across multiple clouds, or running in neo-clouds like Coreweave, Together.ai, Lambda Labs, etc. In such cases, the storage is typically S3, or R2.

There is of course going to be additional latency when S3 is used outside the AWS network. But that is the practical case as well when using S3 in multi-cloud workloads. The same applies to R2, which is often used outside their worker product through compute that is not part of the Cloudflare network infra.

The benchmark uses standard tier for buckets, which tends to be the most common. The blog post should have mentioned the tier. A miss from my side.

What more would you have wanted to see? The benchmark is using the open source go-ycsb tool and is easily reproducible.

Learn how to implement data time travel with Ducklake and Tigris to easily recover from database mishaps. This guide demonstrates how Ducklake creates snapshots for every `INSERT` or `DELETE` operation, allowing you to explore your analytics database as it was before disaster struck.

We added support for this a few months ago in Tigris: https://www.tigrisdata.com/blog/rename-object/ Good to see AWS catching up.

BTW there is another TigerData which predates this rename by a month: https://library.princeton.edu/about/library-news/2025/introd...

If your logging system uses object storage like S3 or Tigris for persistence then it can automatically benefit from storage tiering.

At Tigris, we encountered a pattern where uploaded files included fake CAPTCHA screens as a way to hide malicious payloads and bypass detection.

These fake CAPTCHAs look legitimate but are used to trick users into executing malware, and they're surprisingly effective at evading static analysis.

We shared what we found and how we're improving our detection pipeline: https://www.tigrisdata.com/blog/fake-captchas/