Supabase Storage: major performance, security, and reliability updates

Summary

Supabase Storage has shipped updates live in all regions for projects using Storage, targeting performance at scale, security vulnerabilities, and reliability issues. As projects reached tens of millions of objects, concurrent uploads exposed write bottlenecks, certain SQL deletes could orphan files, and a crafted path could escape the file backend’s storage root. The object-listing rewrite removes the prefixes table, six triggers, and twelve helper functions, derives folder structure from the objects table with a hybrid skip-scan algorithm, and uses cursor-based pagination; deep pagination on 60 million rows is up to 14.8 times faster without a write penalty. Direct SQL deletes are blocked by default through a statement-level trigger, while a configurable 30-second timeout supports cancellation of disconnected clients via native Postgres protocol. Idempotent migrations, TUS lock-race prevention, orphan-scanner fixes, OpenTelemetry metrics, and adapter and API bug fixes are included, with no code changes required.

Takeaways

1. 1

   Object listing no longer uses the prefixes table, six triggers, or twelve helper functions; cursor-based pagination on 60 million rows is up to 14.8 times faster for deep pages without a write penalty.

2. 2

   A statement-level trigger rejects direct DELETE statements on Storage schema tables unless storage.allow_delete_query is enabled; the Storage API sets the variable automatically for normal operations.

3. 3

   Storage metrics now use OpenTelemetry and can be pushed to any OTel-compatible backend, while Prometheus scraping remains available at /metrics through the OTel Prometheus exporter.