第1步：先分清四个选项
做数据库选型时，Kuzu 常被拿来和 Neo4j、SQLite、DuckDB 比。它们其实不在同一条赛道。Kuzu 是嵌入式图数据库，Neo4j 是成熟图数据库服务器，SQLite 是嵌入式关系数据库，DuckDB 是偏分析型的嵌入式列式数据库。
一句话粗暴记：查路径看 Kuzu 或 Neo4j，做本地业务表看 SQLite，做大表分析看 DuckDB。别只因为它们都能被 Python 调用，就以为用途差不多。
kuzu攻略：同类怎么选
kuzu攻略的重点不是“吹哪家强”，而是把 Kuzu、Neo4j、SQLite、DuckDB 这些常见选项放在同一张桌上。你按场景一步步筛，很快能知道自己该用嵌入式图数据库，还是继续用表格数据库。
第2步：按部署方式筛
如果你不想部署服务，只想在应用里带一个数据库，Kuzu、SQLite、DuckDB 都很顺手。程序打开本地文件或目录就能跑，适合桌面工具、命令行工具、离线分析。Neo4j 通常需要启动服务，适合团队共享和长期在线。
所以这一步先问自己：数据库是跟着应用走，还是作为公共服务存在？前者优先看 Kuzu 这类嵌入式方案；后者再认真评估 Neo4j 的生态和运维成本。
第3步：按查询形状筛
Kuzu 对比 SQLite，差异不在“谁更高级”，而在查询形状。SQLite 擅长精确筛选、事务、常规 join。Kuzu 擅长从一个节点出发沿关系扩展，比如查共同好友、依赖链、引用链、设备关联账户。
Kuzu 对比 DuckDB，差异更明显。DuckDB 很适合扫大表、聚合、做 OLAP 分析，比如按月统计、分组排序、读取 Parquet。Kuzu 不主打大宽表扫描，它的优势是图遍历。你要的是报表，选 DuckDB；你要的是关系路径，选 Kuzu。
第4步：按团队和生态筛
Neo4j 的优势是生态成熟：文档、社区、可视化工具、企业功能都更完整。团队里没人想折腾底层细节，预算和部署条件也允许，Neo4j 很稳。Kuzu 的优势是轻，适合把图能力做成产品内部的一部分。
这里的 kuzu攻略 是：别只看技术截图，要看谁来维护。一个人做分析工具，Kuzu 轻松；十几个业务方共用图平台，Neo4j 更像正餐。SQLite 和 DuckDB 则适合团队已经习惯表模型，不需要复杂图遍历的情况。
第5步：用一句话做最终选择
选 Kuzu：你的数据是网络，查询常出现多跳路径，而且想嵌入应用。选 Neo4j：你要完整图数据库服务和成熟工具链。选 SQLite：你要稳定本地关系表和事务。选 DuckDB：你要本地高效分析大表、Parquet、CSV。
最实用的做法是拿一份真实小样本同时试两套。比如 Kuzu 跑路径查询，DuckDB 跑统计分析，SQLite 跑业务状态查询。哪个查询写得短、结果对、维护起来轻，哪个就是更合适的工具。技术选型不是站队，是省后面的时间。
常见问题
- kuzu攻略里最重要的选型标准是什么？
- 看查询是不是以路径和关系扩展为主。如果是，Kuzu 有优势；如果主要是筛选、统计、报表，SQLite 或 DuckDB 往往更合适。
- kuzu和DuckDB可以一起用吗？
- 可以。常见做法是 DuckDB 处理大表清洗和统计，Kuzu 存图结构并做路径查询。两者都适合本地分析工作流。
- kuzu比Neo4j更好吗？
- 不是更好，而是更轻。Kuzu 适合嵌入式、本地、应用内图查询；Neo4j 适合完整图数据库服务、多人使用和成熟生态。