第一版商业 SaaS 数据库，从一家公司的真实需求开始

职业转型期间，有一次和朋友聊天，他提到他们公司一直在用一套 SaaS，按年付费。

我当时认真说了一句：

“如果你们每年订阅那个系统的话，我想试着做一个。”

最开始想得其实很简单。

就是照着他们正在使用的系统，做一套功能和使用场景差不多的 SaaS。那时候没有认真想过产品定位，也没有考虑过行业竞争。

甚至能找到多少客户来用，我都不太在意。

我的想法只是：既然朋友公司本身就在持续付费使用这样一套系统，而且有真实的业务需求，那我可以先做一套替代现有软件的系统，给他们公司使用。

于是我先去看了他们正在使用的软件，大概了解它有哪些功能、解决哪些问题。

后来，在朋友的介绍下，我进一步和实际业务人员做了一次交流。

我开始了解他们日常的工作流程：业务如何流转，哪些环节由系统承载，哪些环节仍然依赖聊天工具或人工协作。

那次聊完以后，我觉得业务已经理解得差不多了。

于是回来开始设计第一版数据库。

当时觉得整个模型已经比较清楚了。

然后，真正的问题是在写 API 的时候才出现。

我决定把第一版推倒重来

根本的问题是：

我对这个行业的理解，主要来自一家公司，以及他们正在使用的一套软件。

如果目标只是给朋友公司做一套内部替代系统，这可能已经够了。

但如果真的准备把它做成商业 SaaS，就不够。

一家公司的工作方式不代表整个行业，一套现有软件的产品设计也不一定就是最合适的答案。

所以我没有继续在第一版数据库上修修补补，而是停下来重新研究产品。

技术上当然可以继续改表、补字段、调整关系，但如果底层的产品假设已经不成立，继续优化只会让自己在错误方向上投入更多。

这一次，我开始研究行业里已经发展多年的成熟产品，也开始看一些边界相近、但来自其他领域的软件。

我更关心的是：

• 它们为什么这样划分业务对象；
• 哪些能力是行业长期沉淀下来的共性；
• 哪些设计只是历史包袱；
• 不同类型的软件，是怎么解决类似协作问题的；
• 哪些环节成熟系统仍然没有解决好。

遇到新的使用场景，再拿回去找行业里的朋友确认。

这个过程做下来以后，真正被重做的其实不只是数据库。

产品定位也重新做了一遍。

我开始认真考虑：如果希望这个产品未来能够服务更多类型的企业，它和已经存在多年的成熟软件相比，为什么值得被选择？

我很清楚，如果直接和已经发展多年的成熟软件正面竞争，无论产品完整度、客户积累还是团队资源，都没有优势。

所以我没有选择去做一个“小号的成熟软件”，而是把范围继续收窄，先找一个足够垂直的小切口。

与其在主战场正面竞争，不如先找到一个自己能够站住的小山头。

有限的开发资源，优先集中在几个差异足够明显、真正值得解决的场景上。

产品边界重新确定以后，我也重新评估了数据库选型。

数据库也重新选了一次

产品重新定位后，我确定未来会需要地理位置能力，也希望为 AI 检索、RAG 和语义搜索预留空间。

而在早期研发阶段，研发和运维资源都非常有限。每多引入一套基础设施，就意味着多一套部署、监控、备份、升级和故障处理。

这时候我重新看了 PostgreSQL。

它可以继续承担核心关系型数据，通过 PostGIS 处理地理空间数据，通过 pgvector 支撑前期的向量存储和检索，同时自身也具备全文搜索能力。

这意味着在产品早期，我暂时不需要同时维护关系数据库、专业向量数据库和 Elasticsearch。

一套 PostgreSQL，就可以先覆盖当前大部分数据场景。

对独立开发来说，好的技术选型不是把未来所有基础设施提前准备好，而是用尽可能少的组件覆盖当前已经确认的需求，同时不给未来的拆分制造障碍。

第一版真正应该控制的，不只是开发成本。

还有未来几年自己需要承担的系统复杂度。

如果未来全文搜索真的复杂到需要 Elasticsearch，或者向量检索超过 pgvector 适合承担的范围，再独立拆出去。现在没有必要提前为还没出现的问题支付复杂度成本。

回头看，第一版数据库真正需要推倒重来的原因，并不是 MySQL 不合适，也不是某几张表设计得不好。

表设计不好，可以改；字段不合理，可以调整；关系没拆清楚，也可以继续重构。

但如果产品定位变了，原来的数据模型即使继续修补，也只是建立在旧的产品假设上。

真正发生变化的，是产品形态和业务场景本身。