选数据库纠结过吗？
项目初期用SQLite，跑着跑着发现不行了，再迁PostgreSQL。我见过太多次这种返工。
其实选择没那么难。核心就一条：你的数据放不放得进一个文件。
先看清楚两个东西的本质
SQLite是什么？一个文件。
整个数据库就是磁盘上一个 .db 文件。数据、索引、日志，全在里面。没有服务器进程，你应用直接读这个文件。
PostgreSQL是什么？一个服务。
要安装、启动、开端口、管连接。但换来的是多进程并发、复制、事务隔离、扩展生态。
本质区别就这一句：
SQLite是"数据就在你手里"，PostgreSQL是"数据在别人的进程里"。
5个判断标准，对着打勾
1. 读写并发量有多大？
SQLite的写操作是全库锁。同一时刻只能有一个写者。
读可以并发，写不行。
如果你的应用每秒要写几千次，SQLite会卡住。每秒几十次写入，SQLite完全够用。
判断标准：写并发 > 100/s，直接PostgreSQL。
2. 数据总量多大？
500MB以下的数据，SQLite查询飞快，文件还能直接备份。
超过50GB，SQLite的文件操作开始吃力。索引管理、VACUUM都会变慢。
判断标准：预计数据量 > 10GB，选PostgreSQL。
3. 要不要多人同时改数据？
多人协作编辑同一批记录，SQLite的锁机制会让用户等很久的写操作。PostgreSQL的MVCC机制天然适合多用户并发读写。
判断标准：有团队多人同时写数据，选PostgreSQL。
4. 要不要复制和容灾？
PostgreSQL原生支持主从复制，一台挂了另一台顶上。SQLite没有这套机制，备份靠定期拷文件。
判断标准：生产环境需要高可用，选PostgreSQL。
5. 部署环境复杂吗？
这是个容易被忽略的点。
做个桌面App、嵌入式设备、移动应用本地存储，装个PostgreSQL太重了。SQLite零依赖，一个动态库搞定。
判断标准：目标环境装不了数据库服务器，选SQLite。
真实场景对号入座
| 场景 | 选择 | 原因 |
|---|---|---|
| 个人记账App本地数据 | SQLite | 单机、单用户、数据小 |
| 博客系统 | SQLite够用 | 读多写少、单实例部署 |
| 电商订单系统 | PostgreSQL | 写并发高、需要事务隔离 |
| 日志分析平台 | PostgreSQL | 数据量大、查询复杂 |
| 嵌入式设备数据 | SQLite | 环境装不了服务器 |
一个反直觉的事实
很多开发者怕SQLite，觉得它"太简单不够用"。
实际上，很多大型系统都在用SQLite。NASA用SQLite存探测器数据，Android和iOS用它存本地数据。Twitter早年也测试过把数据库层换成SQLite的方案。
它不弱，只是不适合高并发写入的服务端场景。
迁移成本不是零
从SQLite迁到PostgreSQL，表结构要手动建，数据要导出导入。业务代码里的SQL也要检查兼容性。比如AUTOINCREMENT要改成SERIAL，日期函数两边写法不同。
反过来从PostgreSQL降到SQLite，基本不可行。
所以选型这件事，最好在第一天就定下来。别等跑起来再改。
你现在的项目用的什么数据库？有遇到"选错了"的时刻吗？评论区说说，帮你看看还能不能救。