做一个新产品或者验证一个想法的时候，数据库选型往往是被过度讨论的话题。很多团队会在项目启动会上争论该用MySQL还是PostgreSQL，然后花半天时间装环境、配账号、开远程访问，结果业务逻辑一行还没写。实际上，原型开发阶段的核心目标是快速验证想法是否成立，而不是搭建一个生产级的数据库集群。SQLite恰好是为这个阶段量身定做的工具：它不需要安装服务，不需要配置，不需要维护连接池，整个数据库就是一个文件，拷走就能用。下面从几个具体角度聊聊为什么它适合这个场景，以及什么时候该放弃它。
零部署成本：把环境搭建时间压缩到接近于零
传统客户端/服务器架构的数据库，在开发阶段的第一步就是部署。以MySQL为例，你需要安装服务端、初始化数据目录、设置root密码、创建业务账号、开放端口，如果团队多人协作还要处理远程访问权限。这些步骤每一步都可能出错，尤其在Windows和macOS上行为还不完全一致。而SQLite是一个嵌入式数据库引擎，它以库的形式直接链接进你的程序进程，第一次访问数据库文件时如果文件不存在，引擎会自动创建。
以Python为例，标准库内置了sqlite3模块，不需要pip安装任何东西：
import sqlite3
# 连接时如果文件不存在会自动创建
conn = sqlite3.connect("prototype.db")
cursor = conn.cursor()
# 直接建表，无需提前创建数据库实例
cursor.execute("""
CREATE TABLE IF NOT EXISTS users (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
email TEXT UNIQUE,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
)
""")
cursor.execute("INSERT INTO users (name, email) VALUES (?, ?)", ("张三", "zhangsan@ipipp.com"))
conn.commit()
for row in cursor.execute("SELECT * FROM users"):
print(row)
这段代码在任何装了Python的机器上都能直接跑起来，没有任何前置条件。Go语言同样只需引入modernc.org/sqlite这类纯Go实现的驱动，Java则直接用JDK自带的驱动即可。对于原型开发来说，这种开箱即用的特性能把注意力完全集中在业务逻辑上。
单文件存储：数据可以随手备份、迁移和分享
SQLite的整棵数据库（包括表、索引、触发器）都存在一个单独的.crossfile文件里，这个特性在原型阶段非常实用。当你想把当前的数据状态发给同事看一下，直接把文件发过去就行；想保留某个版本的快照，复制一份改名即可；想在另一台机器上继续开发，把文件放进项目目录用git管理或者拷到U盘都可以。
对比一下客户端/服务器数据库的做法：备份数据需要执行mysqldump导出SQL，恢复时再导入，中间还可能遇到字符集、版本差异的问题。而SQLite的备份就是文件复制，最多再加上WAL模式下的.backup命令保证一致性。下面是一个开启WAL模式并做备份的示例：
# 进入sqlite3命令行工具 sqlite3 prototype.db -- 开启WAL模式，提升并发读写能力 PRAGMA journal_mode=WAL; -- 退出后直接复制文件即可完成备份 -- Windows下 copy prototype.db prototype_backup.db -- Linux/macOS下 cp prototype.db prototype_backup.db
另外值得一提的是，SQLite数据文件格式跨平台稳定，Windows上创建的数据库文件在Linux服务器上可以直接打开，这在原型开发后期把demo部署到云服务器时特别方便，你甚至可以把数据文件和代码一起打包上传，几分钟就能跑起来一个可演示的版本。
开发体验：完整SQL支持加可视化工具链
很多人对嵌入式数据库有个误解，认为功能残缺只能执行简单查询。实际情况是SQLite对SQL标准的支持相当完整，包括事务、子查询、CTE（公共表表达式）、窗口函数、全文搜索甚至JSON函数。你在原型阶段写出的SQL，绝大部分可以平滑迁移到PostgreSQL或MySQL上，这意味着前期在SQLite上设计的数据模型和查询逻辑不会白费。
比如利用CTE做递归查询：
-- 建一个简单的分类树表
CREATE TABLE categories (
id INTEGER PRIMARY KEY,
name TEXT,
parent_id INTEGER REFERENCES categories(id)
);
-- 用递归CTE查询整棵子树
WITH RECURSIVE sub_tree AS (
SELECT id, name, parent_id FROM categories WHERE id = 1
UNION ALL
SELECT c.id, c.name, c.parent_id
FROM categories c JOIN sub_tree s ON c.parent_id = s.id
)
SELECT * FROM sub_tree;
工具链方面，SQLite生态也很成熟。命令行有官方的sqlite3工具，图形界面有DB Browser for SQLite、DBeaver、Navicat等，都能直接打开数据库文件浏览数据、编辑表结构。配合浏览器的SQLite在线查看插件，调试时把数据文件拖进浏览器就能检查内容，这种便利性是传统数据库很难提供的。
ORM框架的支持也毫无障碍。Python的SQLAlchemy、Django（默认就用SQLite）、Go的GORM、Java的Hibernate，都把SQLite作为一等公民对待，切换数据库通常只改一行连接配置。
局限性：什么时候应该换掉SQLite
当然SQLite不是万能的，它的设计目标是嵌入式场景，官方文档明确说它更适合读多写少、单机部署的应用。以下几种情况说明原型已经长大，该考虑迁移了。
第一是大并发写入。SQLite在同一时刻只允许一个写操作（WAL模式下读写可以并发，但写与写仍然互斥），如果你的应用有多个进程同时高频写入，会遇到database is locked错误。虽然可以通过设置busy_timeout缓解，但本质瓶颈无法绕过。第二是多机部署，数据库文件在文件系统层面无法被多台服务器同时安全访问，NFS等网络文件系统上使用SQLite是明确不推荐的。第三是对用户权限管理有要求，SQLite没有账号体系，任何能访问文件的进程都拥有全部权限。
迁移本身并不痛苦。导出数据用.dump命令生成SQL文件，在目标数据库中执行，再处理少量方言差异（比如AUTOINCREMENT改为AUTO_INCREMENT）即可。更稳妥的做法是在原型阶段就使用ORM，让框架屏蔽SQL方言差异，迁移时基本只需改连接字符串。
# 导出整个数据库为SQL脚本 sqlite3 prototype.db .dump > schema_and_data.sql
总结
原型开发阶段选SQLite的逻辑很简单：把一切非必要的成本砍掉，把时间花在验证业务假设上。零部署、零配置、单文件即数据库、SQL支持完整、工具链成熟，这些特性让它在从想法到可运行demo的路上几乎没有摩擦。等到业务真的跑起来了，遇到并发写入或者多机部署的需求，再带着已经验证过的数据模型平滑迁移到PostgreSQL这类服务器数据库，前后都不浪费。技术选型不必一步到位，合适的阶段用合适的工具，才是工程上的成熟做法。