Supabase Storage now supports the S3 protocol

Original Article ↗ Hacker News Discussion ↗

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.