研究报告 · 约 28,516 字 · 预计推送 3 部分

文档型数据库 vs 关系型数据库：MongoDB、SQLite、PostgreSQL 的个人项目选型 未开始

目录

题记与说明

综合报告（最终稿） · 2026-11-01
本文由同日两份章节报告综合而成：纵轴篇（历时性发展史，八阶段）与横轴篇（2026-11-01 共时性横向对比，九维度）。综合时合并了两章的重复内容、统一了版本与日期口径、修正了彼此出入之处（文中均有标注），全部关键事实保留来源链接。两章中未能直读核实的数据点，本文如实继承其不确定标注，不做补齐。
最终稿修订说明：本稿按独立审读意见逐条修订——补写 MongoDB Search/Vector Search 的可用范围、重写 SQLite 版本口径（逐版本年份、3.52.x 下落、来源归属拆分）、补证 MongoDB 数据库侧校验能力、补全决策树分支并标注文件同步风险、降格 AI 训练数据断言、修正 DB-Engines"分"口径与免费层表述、拆分 SSPL 因果链、新增 §3.5"从决策树到最小起步"；修订处以"（修订：…）"就地注明，未被质疑的内容原样保留。

TL;DR

2026 年做个人项目选型，"文档 vs 关系"的老问题已经失效：三家能力高度趋同——PostgreSQL 用 JSONB + pgvector 吸收了文档库的理由，SQLite 把 JSON 与全文检索装进单文件，MongoDB 补齐了事务与 JOIN。真正决定成败的是三个问题：数据库住在哪（嵌入/托管/自托管）、约束声明在哪一层、退出成本有多高。默认答案已稳固：本地工具选 SQLite；公网部署、要长期长大选 PostgreSQL；MongoDB 仅在 MERN 学习、天然异构文档、想要托管开箱即用（含 Search/Vector Search 免配置）时才有理由（注意 SSPL 与 512MB 免费层上限）。范式之争的终局是吸收而非替代——这是数据库史反复验证的规律。

一、纵轴：发展脉络——两条范式从分立、对抗到趋同

1.0 为什么要先看历史

本课题表面上是"个人项目该用 MongoDB、SQLite 还是 PostgreSQL"的三选一，但纵轴（历时性）视角告诉我们：这个问题的答案在过去五十多年里被反复改写。纵轴不是某一条产品线的编年史，而是文档模型与关系模型这两条范式从分立、对抗到趋同的历史。个人项目选型之所以成为问题，正是因为这条主线不断改变三者的相对位置：

到 2026 年的当下截面，三者已从"替代关系"演变为"各占一个生态位"。下面按八个阶段展开。

1.1 阶段一（1970–1999）：关系模型确立，文档模型的"史前时代"

这一阶段为"个人项目选型"议题埋下了最初的问题框架：好用的个人项目数据库，必须便宜、易装、不需要专职 DBA。

1.2 阶段二（2000–2006）：SQLite 诞生——"反服务器"的关系数据库

这一阶段确立了个人项目选型反复出现的判断标准之一：零运维、单文件、随代码一起拷走。

1.3 阶段三（2006–2009）：NoSQL 浪潮与 MongoDB 诞生——两种模型正面相遇

驱动因素是 Web 2.0 的规模爆炸、廉价横向扩展与开发者"先写业务再定 Schema"的渴望。对个人项目而言，2009 年前后的叙事极具诱惑力——"MongoDB is web scale"成了开发者社区的流行梗，个人项目的默认数据库第一次出现分裂。

1.4 阶段四（2010–2014）：MongoDB 的黄金扩张与第一次信任危机

"易上手"与"可靠"第一次正面冲突，个人项目叙事开始出现第一批"从 MongoDB 迁回 Postgres"的博文。

1.5 阶段五（2014–2018）：JSONB 分水岭——Postgres 吸收文档模型，MongoDB 走向企业化

对个人项目的直接影响：Linux 发行版里 apt install mongodb 开始变得别扭，而"一个 Postgres 同时干关系和文档两份活"的教程大量出现——"Postgres 就够了"由此成为个人项目圈的经典建议。

1.6 阶段六（2019–2022）：本地优先运动与 SQLite 复兴，Postgres 服务化

个人项目选型的三选一格局至此齐备：SQLite（本地/嵌入）、托管 Postgres（默认后端）、Atlas（文档托管）。

1.7 阶段七（2023–2025）：三库趋同，AI 与"vibe coding"改变天平

驱动因素：AI 应用（RAG/Agent）让"向量 + 关系 + 文档"一体化的诉求全面压倒单范式之争；"vibe coding"让个人开发者规模激增，托管 Postgres（Supabase/Neon）成为 AI 编码工具链里的默认持久化选项；本地优先与"一人公司"思潮让 SQLite 重新合法化。三库在能力上趋同（事务、JSON、向量都有），竞争焦点转移到生态位与运维成本。

1.8 阶段八（2026，当下截面）：格局落定

1.9 纵轴的三条启示

  1. 范式之争的终局是吸收而非替代：MongoDB 没有杀死 SQL，Postgres 反而把文档模型变成了一个列类型；SQLite 把 JSON 内置、MongoDB 把事务补齐——到 2026 年，"纯文档 vs 纯关系"的原教旨争论已经没有技术土壤，选型问题真正变成了生态位与托管成本问题。
  2. 个人项目选型被两股力量反复重塑：第一股是运维成本（军舰上没有 DBA → 手机里没有 DBA → 个人开发者的深夜里没有 DBA），第二股是舆论与调查（Jepsen 报告、Stack Overflow 榜单、Rails 8 的站队）。每一次 SQLite/Postgres 生态位扩张，背后都是"让一个人能搞定"的驱动。
  3. 商业矛盾塑造技术版图（修订：原稿把两条因果拧成了一句，拆开写）——SSPL 之争的后果有两条不同的因果链。第一条：云厂商并没有因此转向 Postgres 来替代 MongoDB——AWS 的回应是以自研兼容层绕开 SSPL，2019 年推出 MongoDB 兼容的 DocumentDB，把文档 API 留在自家云上；第二条：真正吃到 SSPL 弃用潮与 AI 浪潮红利的，是托管 Postgres 生态——Supabase、Neon 等平台拿走了"开源 + 托管"的位置（Neon 10 亿美元被 Databricks 收购、Supabase 估值 100 亿美元），AI 浪潮又用真金白银（含 Voyage 2.2 亿美元）加码了这一侧。技术选型从来不只是技术问题——这是纵轴给横轴对比埋下的最重要注脚。

二、横轴：横向对比——2026-11-01 时间截面

2.1 对比集合的界定

横向对比必须把"替代方案"一并拉进来，否则结论会失真：

选择这三个核心对象的理由本身就是课题的一部分：它们恰好代表三种部署形态的极点——进程内嵌（SQLite）、独立服务进程（PostgreSQL）、服务 + 托管平台（MongoDB/Atlas）。

2.2 总览对比表（截至 2026-11-01）

维度SQLitePostgreSQLMongoDB
数据模型关系型（SQL），支持 JSON/JSONB 列关系型 + JSONB（文档能力内嵌）+ pgvector文档型（BSON），Schema 灵活
最新版本3.54.1（2026-10-16）18.x（18.0 于 2025-09-25 发布；19 尚在 RC1）9.0（2026-09-29 GA）
许可证Public Domain（公有领域）PostgreSQL License（类 BSD/MIT）SSPL v1（OSI 未认可，非"开源"定义）
部署形态进程内嵌库，单文件C/S 服务进程服务进程 + Atlas 托管
零成本上限无上限（本地磁盘）自托管无上限；Supabase/Neon 免费层约 0.5GBAtlas M0 免费 512MB
运维负担几乎为零（备份 = 复制文件）中（备份/升级/连接管理，托管可转嫁）中高（托管转嫁，自托管分片/副本集复杂）
向量检索生态层扩展（sqlite-vec、libSQL）pgvector 扩展Search/Vector Search（2025-09 起自托管社区版/企业版可用，见 §2.3.4）
全文检索FTS5 内建tsvector/GIN + pg_trgm 内建Search（2025-09 起自托管社区版可用；此前为 Atlas 专属，见 §2.3.4）
DB-Engines 排名（2026-10/11）*长期第 8 位上下、位列本月上升榜第 4 位（同比 +45 分）第 5 位（同比 +7 分）
个人项目典型角色默认本地存储默认服务端主库特定形态下的文档主库

\* DB-Engines 排名数字来自横轴章的 WebSearch 摘要（db-engines.com 页面直读失败，报证书错误 UNABLE_TO_GET_ISSUER_CERT_LOCALLY；本文 2026-11-01 复试同样失败），使用时建议以当月官网页面复核。（修订补充口径：这里的"分"是 DB-Engines 的流行度评分——每月更新，由搜索引擎命中数、Google Trends、Stack Overflow 等技术讨论频度、招聘信息提及、LinkedIn 档案与社交提及等信号加权合成（排名方法页，检索摘要核实），不是用户量或市场份额；"+45/+7 分"为同比增量（对 2025 年同期），与正文"2026 上半年 +21.97 分"（半年窗口）不可相加或直接比较，绝对增量大小应结合名次走向解读。）

2.3 分维度对比

2.3.1 数据模型与查询能力："文档 vs 关系"在 2026 年还剩多少真实差异

这是本课题的母题，也是横向对比中差异被收窄得最厉害的一维。

逐项结论（修订：补证 MongoDB 数据库侧校验能力，去掉绝对化表述）：三者的能力交集在 2026 年显著大于差集。真正的分水岭不再是"文档 vs 关系"，而是约束缺省声明在哪一层——Postgres/SQLite 在建表时用 schema 约束数据，脏数据缺省进不来；MongoDB 同样提供数据库侧校验：集合上可以挂 $jsonSchema 校验器（3.6 起支持，可配 validationLevel off/moderate/strict 与 validationAction error/warn），但它是逐集合显式开启的可选项，且没有外键与跨文档约束（MongoDB Schema Validation 文档，本文直读核实）——"随手建集合"的个人项目用法下，校验器通常不会被配置，约束缺省仍落在应用层，脏数据要到读代码时才发现。对个人项目而言，没有同事跟你对齐 schema 时，数据库侧的强约束往往是更便宜的那道保险。

2.3.2 许可证与法律风险：最容易被个人开发者忽略的一维

逐项结论：个人项目阶段三者都是零成本，但 SSPL 是一个"未来的坑"而非"现在的成本"，风险仅在"你的个人项目变成 DBaaS 创业产品"那天出现。选型时值得记一笔，不必因此否决。

2.3.3 成本：金钱与心智

金钱成本（免费层与起步价，2026 年）：

方案免费额度付费起步
SQLite 自托管无限（本地文件）$0
PostgreSQL 自托管（VPS）取决于 VPSVPS $4-10/月
Supabase（托管 PG）~2 个项目、约 500MB 库、5GB 流量、闲置暂停（来源：Alternative.tools SaaS 数据库指南、FuturePicker 2026 对比；修订：均为第三方对比页，未直读官方定价页 ⚠）Pro $25/月（同上 ⚠）
Neon（Serverless PG）~100 CU-hours/0.5GB、闲置 5 分钟挂起自动唤醒、支持分支（同上来源，第三方对比页 ⚠）按用量计费
MongoDB Atlas M0/Free512MB 存储、100 库/500 集合、500 并发连接、10GB 出入网（修订：本文 2026-11-01 直读免费层限制文档复核——0.5GB 存储、500 连接、100 库/500 集合、7 天滚动窗口 10GB 进/10GB 出；另见 Atlas 部署教程）Flex 约 $8-30/月；专用 M10+ 约 $57-60/月（来源：MongoDB Pricing；区间来自检索摘要，以官方页为准 ⚠）

心智成本（对个人项目往往更贵）：

逐项结论（修订：原稿"Atlas（512MB）< Supabase/Neon（约 500MB）"的不等号与自身数字相悖，改为按定位表述）：三家免费层的存储都在 0.5GB 量级（Atlas M0 与 Supabase/Neon 约 500MB 相当），真正拉开差距的不是数字而是沙盒定位与可否跑生产：Atlas M0 是沙盒——限流 100 ops/s、30 天闲置可能被平台停用、备份快照最多保留 4 份、专用与分析/搜索节点仅 M10+ 可配（以上为本文直读免费层限制文档所得），生产负载需要升到 Flex/专用层；Supabase/Neon 的免费层定位是可跑小型生产（约 500MB 还捆绑认证/存储等周边能力，代价是闲置暂停与额度管理）；SQLite/自托管无上限。若项目会长大，Postgres 托管路线的单位成本曲线更平。

2.3.4 生态与集成：排名、ORM 与 AI 时代的新变量

逐项结论：以"服务端项目资源多寡"计，生态维度 Postgres > MongoDB > SQLite；换算到"本地项目"场景，SQLite 的嵌入式生态（几乎所有语言标准库级支持）反超。

2.3.5 成熟度与可靠性

2.3.6 运维负担：个人开发者的真实约束是"凌晨谁来救火"

个人项目没有 on-call。于是运维负担的排序（低→高）：SQLite ≈ Atlas/Neon/Supabase 托管 < 自托管 Postgres < 自托管 MongoDB 副本集/分片。一个实用的换算：SQLite 的"数据库运维"退化为"文件备份"；托管的代价从钱变成额度与冷启动（Neon 闲置 5 分钟挂起、Supabase 免费层闲置暂停——对个人低频访问项目，冷启动延迟比额度更先被感知）。

2.3.7 新兴替代方案：SQLite 系正在改写"个人项目选型"的边界

2026 年最值得写进横轴的一支力量是 SQLite 的服务化衍生物：

这些方案对课题的意义："文档 vs 关系"的选择题，正在被"嵌入 vs 服务"的选择题部分取代——而前者在个人项目尺度的权重本来就更低。

2.3.8 适用场景矩阵（个人项目高频形态 × 推荐）

场景首选次选理由
CLI 工具/脚本的本地状态SQLiteDuckDB（分析）零部署、比文件系统更快更省（§2.3.5）
桌面/移动应用内嵌存储SQLitelibSQLPublic Domain 可随包分发
个人网站/博客后端SQLite 或托管 PGSupabase流量小，单文件足够；要认证/存储套件则 Supabase
多用户 SaaS demo托管 Postgres（Neon/Supabase）Atlas Flex强约束 + 免费层可跑生产
RAG/AI 记忆库Postgres + pgvectorAtlas Vector Search一库同时存关系与向量，避免多库同步
全栈学习 MERN 栈MongoDB + Atlas—求职信号一致，JSON 心智模型统一
数据分析/报表DuckDB + SQLite/ParquetPostgres列式 OLAP 与行式 OLTP 分工

2.3.9 迁移与退出成本

2.4 选型决策树（2026-11 版）

（修订：第二问补"多端 + 并发写频繁 + 不上公网"出口；"SQLite + 文件同步"标注适用前提与损坏风险；MongoDB 出口措辞与 Search/Vector Search 可用范围同步。）

数据只在本机/单进程？ ── 是 → SQLite（需要分析加速则加 DuckDB）
        │否
需要多设备访问同一份数据？
  ├─ 几乎无并发写 → SQLite + 文件同步，或 libSQL/Turso
  │     ⚠ 文件同步只适用于"写入已停止"的静止库文件：对正在写入
  │       或带活跃 WAL 日志的库文件做盘对盘/网盘同步，可能拷走
  │       半写状态、直接损坏数据库（与 §2.3.3 备份建议、§3.6 的
  │       告诫口径一致）
  └─ 多端 + 并发写频繁 + 不上公网（如多端笔记应用）→ libSQL/Turso
        （服务模式 / embedded replicas），或轻量托管
        │否（数据要公网服务/多用户）
有公网部署、多用户？
  ├─ 需要认证/存储/实时等全家桶 → Supabase
  ├─ 只要纯数据库、追求弹性 → Neon（或自托管 PG）
  └─ 数据天然异构文档 / MERN 学习目标 / 想要托管版 Search、
     Vector Search 开箱即用 → MongoDB Atlas（先算 512MB 免费层
     够不够；Search/Vector Search 自 2025-09 起社区版自托管亦可用，
     选 Atlas 买的是免配置托管，见 §2.3.4）

2.5 横轴的三条洞察

  1. "文档数据库的理由"正在被关系数据库吸收，而不是相反。 PG 的 JSON_TABLE 与 JSONB、SQLite 的 JSONB、MongoDB 补事务与 JOIN——三方在向彼此移动，但"文档"一侧让出的地盘更大：因为关系约束的不可替代性（数据完整性）高于灵活性的不可替代性（任何时候都可以把 JSON 塞进 JSONB 列）。
  2. 个人项目选型的第一问不是"哪种数据库"，而是"数据库住在哪"。 嵌入（SQLite）、托管（Atlas/Neon/Supabase）、自托管三条部署路线对自由时间的索取，比数据模型的差异更影响项目成败。MongoDB 的真正卖点在今天更多是 Atlas 这层托管体验，而非 BSON 本身。
  3. SQLite 系的边缘化服务化（libSQL/Turso/D1）是 2026 年增量最大的变数：它把"本地简单性"与"服务可达性"焊在一起，恰好击中个人项目"既要零运维又要多设备"的夹缝需求。若其 Rust 重写版成熟，两三年内"个人项目默认 SQLite"的边界会继续外扩。

三、交叉洞察：两条轴合在一起说明了什么

单看纵轴，我们看到的是范式兴衰；单看横轴，我们看到的是参数差异。两条轴交叉之后，才能回答本课题真正的问题：为什么"个人项目选型"在今天长成这个样子，以及你该怎么做。

3.1 历史解释了横轴上"为什么差距只剩这些"

横轴显示三者能力高度趋同，纵轴解释了为什么会这样——因为每一次差距拉大，都触发了一次反向吸收：

交叉结论一：趋同不是巧合，是五十多年"吸收而非替代"规律的最新一轮。 在个人项目尺度上，为"文档模型"本身选 MongoDB 的技术理由已经基本消失，剩下的是生态位理由（见 3.4）。

3.2 纵轴的驱动力解释了横轴的成本结构

纵轴反复出现的两条主线——"没有 DBA"与"商业矛盾"——恰好是横轴成本分析的两根支柱：

交叉结论二：个人项目选型 = 技术能力交集之后的"部署形态 + 商业可持续性"问题。 数据模型这一维在 2026 年已经不足以单独做出决策。

3.3 两轴共同解释了"默认答案"为何稳固

把 Stack Overflow 2026 的调查数据（PostgreSQL 58% 第一、SQLite 42% 超过 MySQL 居第二、MongoDB 19% 第七）放回纵轴时间线上看：这不是一次风向转变，而是四十多年积累的收敛——SQLite 用部署量证明嵌入的价值，Postgres 用"吸收一切"证明扩展的价值，MongoDB 用 Atlas 证明托管的价值。三者的"默认答案"地位各有不同的历史来源，因此都不是靠一轮营销吹起来的，短期也不会翻转。

3.4 对个人开发者的判断与建议

综合两轴，给出可执行的判断清单：

  1. 默认路径：本地工具、CLI、桌面/移动内嵌 → SQLite（当前 3.54.1，Public Domain，备份 = 复制文件）；公网服务、多用户、要长期长大 → PostgreSQL 18.x，优先托管（Supabase 要全家桶、Neon 要弹性与分支、自托管要完全控制）。
  2. MongoDB 的三个明确理由（修订：理由 c 措辞与 Search/Vector Search 可用范围同步）：a) 学习 MERN 全栈、需要与求职市场信号对齐；b) 数据天然是异构文档、聚合管道契合业务查询；c) 想要零配置的托管体验——Search 与 Vector Search 在 Atlas 上开箱即用、备份运维全托管（两者自 2025-09 起在社区版自托管也可用，但需自行部署与运维 Search 组件，见 §2.3.4），且接受 SSPL 与免费层 512MB 上限。三条都不占，就不选它。
  3. 警惕两个"35%"：SQLite 的 35% 是"比文件系统快"（小 blob 场景），MongoDB 9.0 的 35% 是"读取基准比上一代快"——都不是"比对方快 35%"，不要拿营销数字做选型依据。
  4. 把退出成本当一票：SQLite → Postgres 是低摩擦升级路（"先 SQLite 后 Postgres"是低风险策略）；Postgres ↔ MongoDB 是单向门；Supabase/Neon/自托管之间 pg_dump 即走。选"退出成本最低且能力够用"的那条路，而不是"当下最炫"的那条。
  5. AI 项目不必引入第二个库：RAG/记忆库场景，Postgres + pgvector 一库搞定关系 + 向量 + 全文；本地 AI 记忆可以用 SQLite + sqlite-vec。为向量单独引入专业向量库，是团队规模以上的问题。
  6. SSPL 记一笔即可：个人项目阶段三者都是零成本；只有当项目可能变成"对外提供数据库服务"的产品时，SSPL 才成为真风险。

3.5 从决策树到最小起步：装哪个、第一条命令、备份长什么样

（修订新增节：决策树给出"选哪个"，这一节补上"第一步怎么走"。三条默认路线各给安装、建库、备份/连接的最小命令；命令均以官方文档为准，能验证的已验证。）

路线一：SQLite（本地单机的默认起点）

# 安装：几乎零安装——Python 标准库自带 sqlite3 模块；
# 命令行工具可从官网下载页获取（https://www.sqlite.org/download.html）
sqlite3 app.db          # 打开（文件不存在即自动创建）
sqlite3 app.db "CREATE TABLE notes (id INTEGER PRIMARY KEY, body TEXT, created_at TEXT DEFAULT (datetime('now')));"
sqlite3 app.db "INSERT INTO notes (body) VALUES ('hello');"
# 备份（写入期也安全，官方推荐两种方式）：
sqlite3 app.db ".backup app-backup.db"
sqlite3 app.db "VACUUM INTO 'app-backup2.db'"

（以上命令在本文写作环境以 SQLite 3.50.4 实际执行通过：建表、插入、两种备份均成功，查询返回 1|hello|...。）

路线二：PostgreSQL（公网部署、要长期长大）

# 自托管（以 Debian/Ubuntu 为例）：
sudo apt install postgresql
sudo -u postgres createdb myapp                              # 建库
psql "postgresql://postgres:<密码>@localhost:5432/myapp"      # 连接
# 备份/恢复（官方工具链）：
pg_dump -Fc myapp > myapp.dump
pg_restore -d myapp myapp.dump
# 托管路线：Supabase/Neon 控制台建好项目后，
# 直接复制控制台给出的连接串即可（含连接池参数）

（命令为 PostgreSQL 官方文档标准用法；本文环境未安装 PG 服务、未实际执行验证。）

路线三：MongoDB（文档聚合契合 / MERN 学习）

# 托管（个人项目推荐起点）：按官方教程创建免费集群
#   https://www.mongodb.com/docs/atlas/tutorial/deploy-free-tier-cluster/
# 拿到连接串后：
mongosh "mongodb+srv://<user>:<pass>@<cluster>.mongodb.net/"
db.notes.insertOne({ body: "hello" })     # 首次插入即隐式建库建集合
# 备份：免费层可在 Atlas 控制台开启备份（每日快照、最多保留 4 份），
# 或 mongodump --uri="<连接串>"（免费层不支持部分选项，见免费层限制文档）

（Atlas 建免费集群的流程见参考来源的官方部署教程；"免费层可开启备份、每日快照最多保留 4 份"与 mongodump 选项限制为本文 2026-11-01 直读免费层限制文档核实。）

一条原则收尾：先跑通"建库—写一条—备份一次"这个最小闭环，再谈选型优化——三条路线跑通这个闭环的成本差异，本身就是 §2.3.6 运维排序的体感版。

3.6 结论的边界（什么时候本文会失效）

3.7 方法论注记（这次学到什么）

四、参考来源

（合并纵轴章与横轴章的全部来源，按对象分组；标注 ⚠ 的为未能直读核实、仅来自检索摘要或首页级弱指针的条目。）

PostgreSQL

SQLite

MongoDB

SQLite 服务化生态

Postgres 托管平台与 AI 生态

排名与调查

其他

本文继承自两章的未决事项：DB-Engines 排名页直读失败（证书错误，本文复试同样失败）；MongoDB 精确小版本号未逐一核实，以大版本线表述；Atlas Flex/专用档价格区间可能浮动，下单前以官方 Pricing 页为准；PG 19 推迟原因未见官方公告原文；DuckDB、Redis 仅作定性提及、未展开核实。另：横轴章中一处指向本系列向量数据库报告的链接为占位符（example.local），本文未采用。
最终稿新增未决事项：MongoDB 9.0 新闻稿页面直读失败（403），Search/Vector Search 的可用范围以 2025-09-17 自托管公告与 Community Edition 产品页（均为检索摘要）交叉核实；SO 2026 的"最受喜爱数据库"与"Supabase 第 11（8%）"两项未能在调查页复核；CVE-2025-70873 的修复版本归属（随被撤回的 3.52.0）未在一手页面核实。

思考题（读完后想一想，参考答案可展开）

  1. 这篇报告的核心论点是什么？为什么说 2026 年“文档 vs 关系”的选型老问题已经失效？
    参考答案

    核心论点：范式之争的终局是吸收而非替代。2026 年三家高度趋同——PostgreSQL 用 JSONB+pgvector 吸收了文档库的理由，SQLite 把 JSON 与全文检索装进单文件，MongoDB 补齐了事务与 JOIN，“文档vs关系”之争已失效。真正决定成败的是三个问题：数据库住在哪（嵌入/托管/自托管）、约束声明在哪一层、退出成本有多高。

  2. 三家免费层存储都在 0.5GB 量级，报告为什么说真正拉开差距的不是数字，而是“沙盒定位与可否跑生产”？三者分别是什么定位？
    参考答案

    Atlas M0 是沙盒：限流 100 ops/s、30 天闲置可能被平台停用、备份快照最多保留 4 份、专用与分析/搜索节点仅 M10+ 可配，生产负载需升到 Flex/专用层；Supabase/Neon 免费层定位是可跑小型生产，约 500MB 还捆绑认证/存储等周边能力，代价是闲置暂停与额度管理；SQLite/自托管无上限。若项目会长大，Postgres 托管路线的单位成本曲线更平。

  3. 报告提醒了哪些容易被个人开发者忽略的风险或“坑”？
    参考答案

    SSPL：MongoDB 2018 年改用 SSPL v1，OSI 未认可，对外提供服务须开源整个服务管理栈——个人阶段是“未来的坑”，仅当项目变成 DBaaS 产品时才出现。文件同步：对正在写入或带活跃 WAL 的库文件做网盘同步，可能拷走半写状态、直接损坏数据库。两个“35%”：SQLite 指比文件系统快，MongoDB 9.0 指比自家上一代快，不能读作“比对方快 35%”。

  4. 对个人开发者，报告给出的默认选型路径和可执行的行动建议是什么？
    参考答案

    默认路径：本地工具、CLI、桌面/移动内嵌选 SQLite；公网服务、多用户、要长期长大选 PostgreSQL，优先托管。MongoDB 仅剩 MERN 学习、天然异构文档、零配置托管三条理由，不占就不选。行动上：把退出成本当一票——SQLite→Postgres 是低摩擦升级路，Postgres↔MongoDB 是单向门；先跑通“建库—写一条—备份一次”最小闭环再谈优化。

← 资料库今日播报 →