性能没问题，只是你需要自己处理并发访问，数据备份等逻辑

不让用数据库就 json 文件一把梭。sqlite 设计只应对单线程程序访问，放共享存储中也只能同时给一个进程使用

考虑 https://github.com/rqlite/rqlite 么？

SQLite 不适合分布式写入。

要有高的写并发，就得利用 WAL ，尽可能缓冲多点事务，再落盘写入。

而官方说，WAL 模式要求所有进程在同一主机上，不能在网络文件系统上工作：

> All processes using a database must be on the same host computer; WAL does not work ofer a network filesystem. This is because WAL requires all processes to share a small amount of memory and processes on separate host machines obviously cannot share memory with each other.


@wwd179 #12

单机上使用的话，利用好 WAL ，加上外部互斥锁（或者一个进程专门处理写请求），可以实现很高的并发。

这两天我测试过，在电视盒子上（单核 Nginx 默认页压测 1W QPS ，性能不及 6 年前骁龙 636 千元机一半），

Python 的 FastAPI + SQLite + 去年本站被爬的千万数据：

- 200 模拟发帖回帖 + 全文索引 / 秒
- 1100 获取整帖（包括回帖者信息） / 秒

SQLite 的锁是基于文件系统的，所以官方也不建议你把数据库文件扔 NFS 里，主要是有些 NFS 文件系统实现的时候锁的机制做的不好，多线程或多进程访问的时候有可能损坏你的数据库文件。

但有些文件系统的实现是明确说过支持全部的锁机制，没记错的话 AWS 的 EBS 就可以。这种情况下你把 SQLite 文件放上去共享也没问题。

生产用 nas 做数据备份还是把服务部署在 nas 上？

sqlite 不太清楚，h2 这种数据库的 db 文件丢 nas 里面连不了，真实项目踩过坑的，不过我估计 sqlite 应该也差不多

@ConfusedBiscuit sqlite 只支持一写多读，写的时候直接锁表

国产的 go 要求不？😂

既然前提是“数据库访问量不大”，可以单独开发一个后端程序，由它来读写 SQLite ，其它程序必须通过这个后端程序的接口来存取数据，就像网站前后端开发一样。