Supabase Storage now supports the S3 protocol
Supabase has added S3-compatible access to its file storage layer, letting developers plug it into existing S3 tooling and query stored Parquet data directly with engines like DuckDB or ClickHouse while still managing access via PostgreSQL row-level security. Commenters generally praise Supabase’s developer experience, open-source posture, and low pricing, but raise concerns about long‑term independence given VC backing, the relative complexity and limitations of self‑hosting, and missing features such as richer metadata support and S3-style presigned URLs. Several notes highlight that Supabase Storage is an abstraction layer on top of S3 and other S3-compatible backends rather than a replacement for object storage itself, with egress costs and partial S3 API coverage remaining practical considerations.
S3 protocol support & interoperability
- Supabase Storage now exposes an S3‑compatible API, so existing S3 tools (e.g., DuckDB, ClickHouse, CDNs, other S3-compatible storages) can work against it.
- It’s positioned as an “accessibility layer” in front of an S3‑compatible backend, not as a new underlying storage engine.
- Self‑hosters can point it at MinIO or any S3‑compatible store; the hosted service currently uses AWS S3 but “bring your own S3” is planned.
Architecture & capabilities
- Files are stored in S3; only metadata lives in Postgres, enabling SQL queries and Postgres RLS‑based access control.
- The storage layer adds image transforms, caching, cache‑busting, multipart uploads, multiple protocols, and metadata management.
- Atomic, transactional updates across multiple files are not supported; this is left to application logic.
- Static website hosting is not a goal beyond serving HTML under custom domains.
Data science & parquet use cases
- Users highlight querying Parquet directly from Supabase Storage via DuckDB using the S3 API.
- Supabase hints at workflows like dumping Postgres tables to Parquet in Storage and analyzing them with external engines.
Missing / upcoming features
- S3‑style presigned URLs are not yet supported in the S3 interface, though Supabase has its own signed URLs in the standard API and plans to add S3‑equivalent presigning.
- Direct per‑object metadata support is missing and called out as a major gap; it’s stated to be high priority.
- S3 event notifications are not supported; similar behavior can be emulated with database webhooks on the Storage metadata tables.
Performance & pricing
- For uploads, multipart via S3 is fastest for large files (>50 MB, especially >500 MB). For small files (~≤5 MB) differences are minimal; very tiny file benchmarks are “to be checked.”
- Files are served through a built‑in CDN. There is no per‑request pricing; egress is $0.10/GB, which some see as uncompetitive vs B2/R2. Supabase says this is a pass‑through of AWS costs and plans to deploy on other clouds (including Fly.io).
Self‑hosting, openness, and vendor risk
- All components are available as Docker images; Supabase states self‑hosting is fully featured, with configuration via env/docker‑compose and migrations via the CLI.
- Some users report self‑hosting as “challenging” and “neutered” (missing reports, multiple projects, GUI quirks); Supabase disputes this, clarifying that some “missing” items are just configured differently or already present.
- There is visible anxiety about VC backing and potential acquisition/enshittification (drawing parallels to Firebase, Heroku, others). Supabase reiterates no current plans to sell, founder control of the board, and a commitment to open‑source licenses, while acknowledging they cannot guarantee the future.
Ecosystem & standards discussion
- Commenters note the odd but practical status of the proprietary S3 API as a de facto industry standard; “S3‑compatible” is described as a sliding window requiring clear compatibility matrices.
- Supabase documents exactly which S3 APIs it supports and explicitly does not aim for AWS‑specific functionality.