[Storage] Native Object Versioning and Edit Locking / Concurrency Support

[Joao-Tiago-Almeida]

We are evaluating Supabase Storage for a workflow where files are edited multiple times over their lifetime, and we need clearer guidance on how to support two related capabilities: keeping historical versions of a file, and handling concurrent edits safely.

The current Storage API exposes each object path as a single mutable file. For our use case this means we have to implement custom logic to store each revision separately (by rewriting paths) and then maintain a version mapping in Postgres. Before committing to that, I’d like to understand whether native object versioning is planned. Specifically:

Will Supabase Storage support multiple versions of the same object at the same path, with a way to list versions and retrieve a specific historical revision?

If versioning is part of the roadmap, is there any rough timeline or stage you can share?

A second requirement is the ability to avoid conflicting edits when multiple users try to modify the same file. This isn’t about compliance-oriented WORM retention, but about basic edit coordination. Ideally this would be either a true lock (preventing others from modifying the file while someone is editing it) or an optimistic concurrency mechanism (such as conditional writes based on version identifiers).

Questions here:

Are there plans for any native locking or concurrency features for Storage?

Would Supabase consider simple primitives such as “lock/unlock” operations or conditional updates?

If not, is there a recommended pattern for implementing this on top of Postgres and the current Storage API?

The combination of version history and safe editing is important for any system where files evolve over time. Understanding the direction for these features would help us decide between building our own versioning/locking layer or waiting for native support.

Thanks for any guidance or roadmap information you can share.

---

João Almeida | Founding Engineer @ DOJO AI

[lewiii254]

Supabase Storage doesn’t currently support native object versioning or built-in locking/concurrency controls. Each path points to a single mutable file, and there’s no way yet to list or retrieve historical versions.

Versioning has been discussed internally, but there’s no public timeline. Same for Storage-level locks or conditional writes — not on the immediate roadmap.

Today the recommended approach is app-level logic using Postgres:

• Store each file revision under its own generated path.
• Keep a file_versions table that maps versions to Storage paths.
• Use Postgres for concurrency — either optimistic updates (UPDATE … WHERE version = X) or a simple locks table for temporary edit locks.

This pattern is how most teams implement safe editing + version history until native support is added.