Open bombillazo opened 4 months ago
@bombillazo I generally agree that allowing Storing arbritary metadata could be a nice feature to have in Storage. Will add this on the roadmap! 🎉
strong agree on adding custom metadata per storge object. Having to maintain a mirror table just for additional data is a pain, especially the lack of usable triggers to keep both sides in sync.
+2 for this. I would definitely like this. would like to tag files that are being uploaded.
+1
+1 for this
Also +1
Would make multi tenant systems a lot easier to manage. Ie. tenants quota. | +1
+1
+1000000000
I'm currently having to add metadata into my file names, so would love to clean up this mess!
+1 for this. I'm currently working with AI generated images and need to store the prediction parameters that generated each image. Otherwise I gotta use AWS S3 cuz I know they have metadata feature.
+1
+1 looking forward to this
+1
+1
+1 looking for same
This would improve my workflow with supabase as well. Right now, I need to keep a separate table and keep it in sync every time i upload, move or delete objects.
+1
I switched from self hosting to supabase, closed down my own s3 bucket to use supabase storage, and now I can't store metadata on the objects... Please please please add this functionality!
+1 seems very helpful!!
+1
+999 would really help out majorly in making supabase storage my go to for all apps. Currently having to use alternatives despite using supabase db and auth
Great request.
@fenos on this topic, since we're not sure when we might get this, is it wise to add a custom trigger to the storage
schema so that when a DELETE event happens on the objects table, we can automatically delete it in our metadata table?
These are the types of things having a dedicated file_metadata
field would prevent so we wouldn't have to sync data and resources across tables.
+1
+1 it could prevent extra table for metadata
Feature Request
Currently, the
objects
schema in the Storage API schema is a light abstraction over the S3 storage. There is a metadata column in theobjects
table, but it corresponds to the metadata of the S3 file and cannot be used by the user. The API does not expose any way to add related metadata to a file to the objects directly. This metadata would ideally be in JSON format to contain user-determined data. Currently, the user needs to get around this limitation by either:storage.objects
table. This dramatically complicates querying, migrations, and client usage for something that could be colocated within the same table.storage
schema to add this new functionality, potentially breaking compatibility with Supabase-controlled services and implementation.The storage API should natively support metadata, and the API / JS clients should be updated to enable this powerful and common feature for file storage management. My proposal is to add a new column called
file_metadata
to differentiate it to the currentmetadata
field.