为何部署在Heroku的DRF应用使用sqlite3时数据自动清除？如何永久存储？

这个问题的根源是Heroku运行环境的机制和你当前使用的SQLite存储模式存在本质冲突：

• Heroku上的应用运行实例（Dyno）自带临时文件系统（Ephemeral Filesystem）：所有在实例运行期间写入本地磁盘的内容，都会在以下场景被完全清除，不会做任何持久化留存：
  • 应用重新部署、更新代码版本时
  • Dyno因空闲达到阈值进入休眠后重新唤醒时
  • 平台因负载调度、实例故障自动替换运行的Dyno时
  • Dyno因运行配额耗尽被平台回收时
• SQLite3本质是存储在应用本地磁盘的单文件数据库，不属于独立的跨实例存储服务。你通过Admin后台创建的用户、模型对象，本质都是写入了这个临时磁盘上的SQLite文件，只要触发上述任意一种Dyno状态变更，这些数据就会被全部清除，这就是你观察到“数据生成一段时间后自动被系统清除”的核心原因。

补充提醒：不要试图通过反复提交代码、上传更新后的SQLite文件的方式留存数据，这种操作不仅效率极低，在多实例运行场景下还会出现数据不一致的问题，完全不适合承载正式的应用数据。

要实现可靠的永久数据存储，核心是把存储层和应用运行的临时实例完全解耦，成熟可行的方案包括：

• 替换本地SQLite3为平台配套的托管关系型数据库服务：这类服务是独立于Dyno运行的专用存储实例，生命周期和应用运行实例完全分离，不会因为Dyno的重启、替换、休眠丢失数据。对接Django时只需要在项目的settings.py中读取托管数据库提供的连接字符串，替换原有的SQLite配置即可，几乎不需要改动现有业务代码，是最适配Django REST Framework这类Web应用的存储方案。
• 如果业务涉及用户上传附件、静态资源等非结构化数据，不要将这类文件存在应用本地的临时磁盘上，应搭配独立的对象存储服务做持久化存储，避免文件随Dyno状态变更丢失。
• 不推荐通过定时备份SQLite文件到第三方存储的方式做持久化：这种方案的可靠性远低于独立托管数据库，还会存在多实例下的数据写入冲突、备份延迟等问题，无法支撑正式应用的稳定运行。

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