Postgres存储小文件：bytea类型与自定义字节串方案实践咨询

我之前在几个项目里处理过1-10MB小文件的存储需求，刚好对比过这两种方案，说下实际感受：

关于bytea的实际体验 #

• 性能更优：3-5MB的文件，bytea的读写速度明显比自定义编码（比如base64）快。一方面是bytea存储体积和原文件一致，而base64编码后会膨胀约30%，占用更多存储空间和IO；另一方面，bytea不需要额外的编解码步骤，批量读写的时候，这个性能差距会被放大——我之前测过批量插入100个5MB文件，bytea比base64编码快了近40%。
• 开发成本低：PostgreSQL的bytea是原生类型，主流ORM框架（比如SQLAlchemy、JPA、Django ORM）都直接支持，不用自己写编解码的工具类，减少了出错概率。比如用Python的SQLAlchemy，直接把bytes类型的值赋值给字段就行，框架会自动处理和数据库的交互。
• 数据库层面操作灵活：可以直接用PostgreSQL的二进制相关函数，比如md5(bytea_column)直接计算文件哈希，substring(bytea_column, 1, 1024)取文件前1KB内容，这些操作不用先把数据解码成字节数组，效率很高。

关于自定义编码字节串的体验 #

• 适用场景极少：除非你的系统需要兼容不支持bytea的老旧数据库，或者必须把文件内容放到纯文本格式的存储（比如某些配置文件），否则完全没必要自己做编码。我之前试过一次为了兼容某个只能存字符串的第三方接口，把文件转成base64存在数据库里，结果后期维护的时候，因为不同语言的base64换行规则不一致，出现过几次数据损坏的问题，排查起来很麻烦。
• 额外维护成本高：需要自己维护编解码的逻辑，比如统一编码格式、处理异常情况（比如编码失败、解码后字节数不对），这些都是潜在的bug点，而且后续如果要切换存储方式，迁移数据也更麻烦。

总结 #

如果你的系统就是基于PostgreSQL，存储3-5MB的小文件，直接用bytea就好——性能好、开发省事儿、后期维护成本低。自定义编码字节串完全是给自己增加不必要的工作量，没有明显的优势。

内容的提问来源于stack exchange，提问作者ochi