近日，Supabase 宣布对其存储服务 Storage 进行了一系列重大更新，涉及性能优化、安全漏洞修复以及可靠性改进。这些更新已立即生效，影响所有使用 Storage 的项目，旨在解决随着规模扩大而暴露的诸多问题，并为开发者提供更稳定、高效的对象存储体验。
核心改进：对象列表性能提升 14.8 倍
在众多更新中，最引人注目的是 Storage 对象列表功能的重写。原有系统依赖一个包含六条触发器和十二个辅助函数的 prefixes 表来维护文件夹结构，但在大容量存储桶和高并发写入场景下，这些触发器成为性能瓶颈，严重拖慢写入速度。
Supabase 团队采用了一种混合跳跃扫描算法，彻底移除了 prefixes 表，改为在读取时从 objects 表动态推导文件夹结构。同时，分页方式也从基于偏移量（OFFSET）改为基于游标（cursor），使得深度分页的耗时变得恒定。测试数据显示，在包含 6000 万行记录的表上，深度分页速度提升了 14.8 倍 ，且写入性能不再受触发器影响。此外，level 列和两个索引也被移除，进一步简化了架构。
安全加固：堵住路径遍历与意外删除漏洞
安全性方面，本次更新修复了一个文件后端存在的路径遍历漏洞------此前攻击者可能通过精心构造的路径逃逸存储根目录。现在，文件后端已严格限制读写操作只能在配置的存储路径内进行。
另一个常见问题是用户直接在 SQL 中执行 DELETE FROM storage.objects 导致数据库记录被删除而实际文件残留，形成孤立对象。新版本通过语句级触发器阻止了此类直接删除，除非显式设置会话变量 storage.allow_delete_query 为 true。Storage API 会自动设置该变量，因此常规操作不受影响，但意外删除的风险被彻底消除。
可靠性增强：幂等迁移与锁竞争修复
为了提升服务稳定性，Supabase 对 Storage 的迁移系统进行了改造，所有迁移现在都是幂等的。这意味着开发者可以安全地重置迁移表并重放整个迁移链而不会出错，CI 流程也增加了双重验证，避免迁移卡住的问题。
针对 TUS 可恢复上传，团队修复了 S3 锁存器中的竞争条件。此前在锁续约期间，若锁恰好被释放，可能导致死锁无法自动过期。现在续约逻辑会先检查锁状态，确保锁的正确释放。此外，孤立对象扫描器也得到了改进：S3 前缀现在使用尾部斜杠防止误匹配（如 images/ 不会匹配 images2），并支持多个存储桶的批量删除控制。
可观测性升级：引入 OpenTelemetry
在监控和调试方面，Storage 现在采用 OpenTelemetry 替代原有的 prom-client 收集指标，可推送到任何兼容 OTel 的后端。同时，/metrics 端点仍支持 Prometheus 抓取，并附带更新后的 Grafana 仪表盘和 OTel Collector 配置。请求日志中也增加了服务器端执行时间字段，便于性能分析。
多项错误修复
除了上述主要更新，本次发布还包含大量错误修复，例如：
-
修复 TUS 上传 URL 中的双斜杠问题；
-
将
PutVector端点的请求体限制从 1.6 MB 提高到 20 MB； -
修复无效 S3 响应头覆盖导致请求崩溃的问题；
-
修正缺失 Content-Type 时的错误回退类型；
-
解决 Linux 文件后端扩展属性冲突（content-type 和 etag 使用同一属性导致覆盖）；
-
确保
listV1接口返回的文件夹前缀大小写与原文件夹一致等。
结语
此次 Storage 的更新充分体现了 Supabase 在应对规模化挑战时的技术投入。通过重写核心算法、强化安全边界、提升可观测性，Supabase 不仅解决了现有用户的痛点，也为未来更大规模的应用奠定了坚实基础。对于依赖 Supabase Storage 的开发者而言，这些改进将带来更流畅的开发体验和更可靠的存储服务，尤其是深度分页性能的飞跃，将显著优化处理海量对象时的交互效率。
随着数据量的持续增长，云原生数据库与存储服务的竞争已从功能丰富转向规模化下的稳定与性能。Supabase 此次的主动优化，无疑会巩固其在开发者社区中的地位，并吸引更多追求高性能与安全性的企业级用户。