适用人群：个人开发者、小团队、学生项目、内部工具搭建者
核心目标：在不增加服务器成本的前提下，选择资源占用最小或永久免费的数据库方案

很多开发者在使用低价云服务器（如 1核2G / 2核4G 配置）部署 Web 应用时，常因数据库内存占用过高导致系统卡顿甚至 OOM（Out of Memory）。本文将从两个维度为你提供零成本解决方案：

1. 本地部署：在最小内存/磁盘占用前提下，数据库能支撑多大业务规模？
2. 托管服务：哪些平台提供真正长期免费的数据库？免费的硬性边界是什么？

---

一、本地部署方案：SQLite —— 资源占用趋近于零，极限能力远超想象

✅ 资源占用实测（Linux 环境）

• 内存占用：0 MB 后台进程，仅在读写时短暂加载页到内存（通常 < 5 MB）
• 磁盘占用：空数据库约 8 KB；每千行结构化数据约 100 KB ~ 1 MB（取决于字段类型）
• CPU 开销：极低，无连接池、无日志回放、无主从同步

💡 换句话说：SQLite 几乎不消耗服务器资源，特别适合与 Web 服务共存于低配机器。

📈 理论支持上限（保守估计）

指标	安全上限（单机 SQLite）
单表行数	100 万行以内（官方支持 2^63 行，但实际受文件系统限制）
并发写入	< 10 次/秒（写操作会锁整个数据库）
总数据量	< 10 GB（推荐 ≤ 1 GB 以保证性能）
用户规模	日活 ≤ 100 人、同时操作 ≤ 5 人 的 Web 应用完全胜任

⚠️ 注意：SQLite 不适合高频写入或强事务场景（如支付系统），但对于管理后台、博客、问卷、工单系统、内部 CRM 等低频交互应用，绰绰有余。

🔧 部署建议

• 数据库文件路径：/var/lib/myapp/data.db
• 权限设置：确保 Web 进程用户（如 www-data）有读写权限
• 启用 WAL 模式提升并发读性能：

  PRAGMA journal_mode = WAL;
  

✅ 结论：只要你的应用不是高并发写入型，SQLite 可在 4GB 服务器上稳定支撑数百用户、数万条数据，且几乎不占额外资源。

---

二、免费托管数据库方案：哪些能“一直免费”？

部分开发者希望彻底卸载数据库负担，将数据托管到云端。以下是主流平台的免费策略本质分析：

1. Supabase（PostgreSQL 托管）

• 免费类型：永久免费（Hobby Tier）
• 硬性限制：
  • 数据库存储：≤ 500 MB
  • 项目数量：1 个（免费账户）
  • 并发连接数：≤ 20
  • 带宽/请求：未明确限制，但禁止滥用（如爬虫、高频刷接口）
• 关键点：只要你的数据总量 不超过 500 MB，就可以无限期免费使用，无需绑定信用卡。

📌 举例：假设每条记录平均 1 KB，则 500 MB ≈ 50 万条记录。对绝大多数小项目而言，这是“用不完”的容量。

2. PlanetScale（MySQL 兼容，基于 Vitess）

• 免费类型：永久免费（Developer Plan）
• 硬性限制：
  • 存储空间：≤ 5 GB
  • 分支数量：3 个（main + 2 dev）
  • 查询次数：≤ 10,000 次/天
  • 不支持本地事务（需通过 branching 管理 schema 变更）
• 关键点：5 GB 存储 + 1 万次查询/天，对日活 < 500 的应用基本无压力。

3. Firebase Firestore（NoSQL）

• 免费类型：永久免费（Spark Plan）
• 硬性限制：
  • 存储：1 GB
  • 读取：50,000 次/天
  • 写入：20,000 次/天
  • 同时连接：100 个
• 适合：结构灵活、实时同步需求强的应用（如聊天、协作工具）

❗ 注意：以上三家均无需信用卡即可注册使用免费套餐，且只要不突破限额，永远不会收费。

---

三、如何选择？一张表帮你决策

需求特征	推荐方案
服务器资源紧张（≤4GB），追求极致轻量	✅ SQLite（本地）
数据量 < 500 MB，希望免运维、支持远程访问	✅ Supabase（永久免费）
偏好 MySQL 语法，数据量 < 5 GB	✅ PlanetScale（永久免费）
需要实时同步、灵活 Schema	✅ Firebase Firestore（永久免费）
数据敏感，不能出内网	✅ SQLite

---

四、总结

• SQLite 在资源占用趋近于零的前提下，可稳定支撑日活百人级、数据量百万行以内的小型应用。
• Supabase / PlanetScale / Firebase 均提供真正永久免费的数据库服务，只要你的使用量不超过其公开限额（如 500 MB、5 GB、1 万次查询等），就无需担心费用问题。

技术选型的本质，不是追求“最强大”，而是“刚刚好”。
在资源受限的环境中，轻量、简单、可靠的方案，往往才是最优解。