用 sqlite 来当 toB 应用的数据库怎么样

数据量估计撑死就几万条

写 json 文件当数据都毫无压力，大胆用 sqlite 吧，😃

sqlite 的读写还是单线程吧，反正 opencode codex 这种，数据一多明显卡顿

做好文件备份就行

一年几万条不是随便搞,你用 json 文件都没问题

少量并发用户、单线程多半没啥问题，如果用户数多一点，还是用 pg/mysql 这类，出了问题也赖不上你

现在不是还有 pg-lite,rqlite,duckdb 这些玩意儿吗,应该都可以有所弥补,也足够轻量

可以说毫无压力，万一真碰到性能问题迁移就是了

可以是可以，但是文件数据库在并发写上有缺陷，你要看看你的业务场景有没有并发写的使用情况，如果有，不建议用。

用单机 redis 都没问题，我用了五六年了

数据总量不超过内存的, 锁保护 JSON 单文件即可.

我记得 QQ 和微信的数据就是采用 sqlite 做的存储（不知道现在是不是还这样），如果担心并发写的问题，可以启用 wal 特性。

负载肯定没问题，问题是这个系统是单机的使用吗？

其实 sqlite 只要不是高并发,是能够撑起大型项目的,遇到瓶颈了说明业务量已经很可观了

性能没问题，就是 SQL 语法不是很灵活，看你查询复杂度了，虽然 ai 会写，但如果查询太绕还是会变慢。

想好，长大了怎么办就行。

没事，我们一年几个 G 的数据也是用的 sqlite,主要是并发处理好就行

几十人随便造，怎么简单怎么来

和负载性质有关 sqlite 的问题主要在写那端
一年几万行不应该有问题

我曾经有个日千万 pv 的网站用的就是 sqlite （主数据表初始上线时差不多二十万条，每次用户执行查询操作都会把关键词写日志表，后台有一条进程一直在查询日志表，发现有用户的关键词在主数据表搜索不到记录就会去其它地方抓数据写入主数据表然后清掉该日志记录，每周彻底清空一次日志表清掉那些确实抓不到数据的关键词）就这级别用 sqlite 都很轻松，给你参考一下。

sqlite 还是注意备份好

这么点人没啥问题，一年 10 万条数据都行，有并发需求的才不用 SQLite