[dperfect]

Awesome to see supabase constantly improving. Been using supabase for the past few weeks and have really enjoyed it!

I was a bit surprised, however, that there's not currently a good way to reference storage objects from my postgres tables. I found that the recommended way is to store the object's path (as a string) in the database. While that works, it isn't optimal as I'd like to enforce consistency between the object and the table referencing it.

I've tried referencing the id of the corresponding row in the storage.objects table, but (1) apparently the schema supabase uses to manage storage.objects may change, and (2) it still requires separate (non-atomic) operations - or additional triggers - for keeping things in sync. Using buckets (corresponding to tables) and folders with ids is another way to work around it, but still feels suboptimal.

Not 100% sure what the best solution would look like, but ideally the supabase client could emulate storage operations for objects "attached" to a given table record, and supabase (the backend piece) could implement them as atomic operations (e.g., uploading the actual storage asset, storing the necessary metadata, and updating my table row to reference the newly-created storage object; exposing a helper function to return the URLs for any storage objects attached to a record; etc).

Anyway, just a suggestion. Keep up the great work!

[kiwicopple]

this is a similar issue we face with Auth. We want to give direct access to the data/tables, and at the same time we need some flexibility to alter the tables on rare occasions.

We've dabbled with the idea of offering versioned views which have a "set" interface (eg `storage_v1`, `storage_v2`). We're still debating all the ways that we might do it.

All that to say - we're aware that this experience can be improved and we're working on it.