HN讨论 · 身份未知
数十TB数据库在单卷容量限制下的跨卷存储管理
数据库规模增长到40TB，超出云厂商单卷容量上限（Hetzner最多10TB/卷，AWS EBS最大64TB）。作者不得不手工学习并使用btrfs、ZFS合并卷或PostgreSQL tablespace将数据分散到多个存储卷，同时处理写放大等性能问题。
查看原始信号hn:49227635
目标用户
运行大型数据库的独立开发者和运维人员（如自托管SaaS、数据密集型应用），数据库规模已超过单个存储卷的容量上限。
潜在需求
需要一种简单可靠的方式，将超过单卷容量的数据库分散到多个存储卷，同时避免手工配置文件系统池或数据库对象位置的高学习成本和维护负担，并保持I/O性能不受明显损失。
发生场景
一个仅运行两年的应用数据库已增长到40TB，而Hetzner单卷上限10TB（裸机NVMe 24TB），AWS最大EBS卷64TB。作者发现需要学习表空间、btrfs合并卷或把索引/表拆分到不同卷。有评论者在35TB时分离pg_wal到独立卷以解决写放大吃掉NVMe吞吐的问题，还有评论者用ZFS合并多个10TB卷实现45TB存储。
来源证据
一个运行两年的应用数据库已达40TB，超出Hetzner单卷10TB上限和AWS EBS 64TB上限，作者因此需要学习用btrfs合并卷或tablespace拆分表来跨卷存储数据。
When I migrate my infra to Hetzner There are a few disk limit such ad max 10TB per volume. On bare metal, max I can get for nvme is 24tb. I though i never hot these I found myself now learning table space, btrfs to join multiple volume or sepearate index/table into different volume. my database now even for a 2 years app get to 40tb. I looked around and even on aws boggest ebs volume is 64tb. what storage you are using? and what size is it?https://news.ycombinator.com/item?id=49227635
为什么值得留意
一个两年应用就达到40TB数据库，说明大规模数据库存储不再是超大公司的专属问题。提问者与评论者的解决方案各不相同但都依赖手动运维操作，且评论者承认方案“不完美”，反映出跨卷数据库存储这一具体且实用需求值得关注。
已有方案
- 使用btrfs合并多个卷
- 使用ZFS合并多个10TB卷
- 使用PostgreSQL tablespace将索引/表拆分到不同卷
未满足部分
- 现有方案依赖手工配置文件系统池或数据库对象位置，学习成本高
- 合并卷方案可导致写放大等性能问题，需要额外调优（如分离pg_wal）
- 评论者称方案“not perfect”，仍存在不理想的权衡
可能延伸 · 模型推测
- 自动检测数据库规模并推荐或执行跨卷布局的工具
- 面向数据库存储感知的文件系统层，透明管理多卷扩容
- 数据库自带的表空间自动管理与数据分布优化
- 针对单卷容量限制的数据库分片或归档策略
目前未知
- 提问者使用的数据库类型未明确（评论涉及Postgres，但不能确认）
- 硬件配置（网络、IOPS）与具体工作负载未描述
- 其他类似规模的用户是否普遍遇到同样问题未验证
继续核实
- 不同云厂商/裸机环境下，单卷容量上限的实际分布如何？
- 对于数十TB数据库，跨卷存储方案（ZFS、btrfs、tablespace）在运维复杂度和性能上的取舍有哪些？
- 是否有工具能自动化跨卷数据库扩容以减少手工操作？
- 数据库增长到数十TB的应用通常属于哪些业务场景？
主题词
database storagevolume capacity limitsfilesystem poolingtablespace management