supabase/supabase
Storage
Studio's interface for managing buckets, objects, S3 keys, image transformations, and the newer vector / Iceberg storage primitives.
Studio surfaces involved
| Folder | Purpose |
|---|---|
apps/studio/components/interfaces/Storage/ |
All storage UIs — bucket browser, file viewer, settings, S3 keys. |
Data layer
Under apps/studio/data/storage/. The folder is large because Storage has grown several adjacent primitives (analytics buckets, vector buckets, Iceberg, S3 vectors). Highlights:
| File | What it does |
|---|---|
buckets-query.ts, buckets-max-size-limit-query.ts, public-buckets-with-select-policies-query.ts |
List buckets and their configurations. |
bucket-create-mutation.ts, bucket-delete-mutation.ts, bucket-empty-mutation.ts, bucket-update-mutation.ts |
Bucket CRUD. |
bucket-objects-list-mutation.ts, bucket-object-delete-mutation.ts, bucket-object-sign-mutation.ts, bucket-object-get-public-url-mutation.ts, bucket-prefix-delete-mutation.ts, object-move-mutation.ts |
Object operations. |
s3-access-key-create-mutation.ts, s3-access-key-query.ts, s3-access-key-delete-mutation.ts, s3-access-key-keys.ts |
S3 access key management. |
analytics-bucket-create-mutation.ts, analytics-bucket-delete-mutation.ts, analytics-buckets-query.ts |
Analytics buckets. |
iceberg-namespace-*, iceberg-namespace-table-*, iceberg-namespaces-query.ts, iceberg-namespace-tables-query.ts, iceberg-wrapper-create-mutation.ts |
Iceberg integration. |
vector-bucket-*, vector-buckets-indexes-query.ts, vector-buckets-query.ts, vector-bucket-index-*, vector-bucket-query.ts, s3-vectors-wrapper-create-mutation.ts |
Vector storage. |
storage-archive-create-mutation.ts, storage-archive-query.ts |
Archive flows. |
bucket-util.ts |
Shared utilities. |
keys.ts |
React-Query key factory. |
The presence of analytics-, iceberg-, and vector- modules signals that Storage in Supabase has expanded beyond traditional S3-style file storage into analytics-grade and embedding workloads. Each of those are surfaced under separate Studio sections, but they share a single data/storage/ folder.
How file uploads work
Studio uploads files to the Storage service via the tus-js-client-based resumable protocol. The flow:
sequenceDiagram
participant UI as Storage/Files UI
participant Tus as tus-js-client
participant API as Mgmt API / Storage
participant S3 as S3 (or compatible backend)
UI->>Tus: createUpload(file)
Tus->>API: POST /v1/object (TUS init)
API->>S3: multipart init
Tus->>API: PATCH chunks
API->>S3: PUT parts
Tus->>API: POST finalize
API->>S3: complete
API-->>Tus: 200
Tus-->>UI: success → invalidate listingsFor pre-signed URLs (public links, signed downloads), the relevant mutations call /object/sign/* endpoints and the resulting URLs are surfaced in the UI.
Integration points
- Storage upstream service (
supabase/storage) — the runtime API. - imgproxy — image transformation. Used for previews and rendering.
- Iceberg / S3-vectors — newer storage primitives wrapped via FDW (
packages/pg-meta'spg-meta-foreign-tables.ts).
Self-host
In docker/docker-compose.yml, Storage runs as the storage service against either a local S3 or a real S3 provider; image transforms are served by the imgproxy service.
Entry points for modification
- New bucket setting → extend
bucket-update-mutation.tsand the relevant settings UI. - New file operation → add a mutation under
data/storage/and surface it via theStorage/Filesbrowser. - New storage backend → extend the wrappers (e.g.
iceberg-wrapper-create-mutation.ts) and the corresponding Studio section.
Built by Factory AutoWiki from public repository content. It is a generated preview for codebase exploration, not source-maintained documentation.