初创公司用不使用NoSQL其实挺纠结的，得看具体情况和需求吧

（知乎）

看到有人讨论初创公司该不该用NoSQL,说实话这事儿真没标准答案，我呆过两家初创团队，一家死磕PostgreSQL从头用到尾，另一家上来就奔着MongoDB折腾，最后都活下来了，但踩的坑完全不是一回事。

先说说那个坚持用传统数据库的团队,当时我们要做个内容聚合平台，需要处理大量文本数据，技术负责人老张是数据库老兵，他拍板说：“咱们这业务结构清晰，关联查询多，用PostgreSQL足够，别瞎追新潮。”结果头半年特别顺，表关系设计得明明白白，SQL语句写得飞起，但后来问题来了——用户行为数据暴增，我们要实时分析用户点击偏好，PostgreSQL的单机写入先顶不住了，有次大促活动，数据库CPU直接飙到98%，紧急扩容时才发现关系型数据库的水平扩展这么费劲，最后是靠砸钱买高配云数据库扛过去的，老张那阵子天天念叨“早知道当年该留个文档数据库的口子”。

另一家做社交游戏的公司就反着来,CTO是硅谷回来的，立项会上就说：“咱们用户增长要爆发，必须用MongoDB！”刚开始确实爽，用户画像这种JSON数据往库里一扔就行，加个新字段连迁移脚本都不用写，但很快也傻眼了——有次运营要查“充值超过100元且连续登录7天的女性用户”，几个程序员对着MongoDB的聚合管道折腾了两天，写出来的查询比SQL复杂三倍，更坑的是有次误操作删了字段，因为没固定schema，等发现时数据已经乱成一锅粥。

后来我慢慢琢磨明白了,选不选NoSQL关键看三点：第一是数据会不会“变脸”，像我们做社交游戏时，今天加个宠物系统明天加个成就徽章，关系数据库改表结构能改到吐血，NoSQL的灵活schema真是救星。第二是扩展要不要“分家”，如果像电商那样订单、用户、商品天然能分到不同服务器，NoSQL的分片能力就显优势；但要是像金融系统整天要跨表事务，硬上NoSQL就是找死。第三是团队能不能“降妖”，用NoSQL得自己管数据一致性，开发人员要是连ACID和BASE都搞不清，迟早把数据库玩坏。

现在我自己带团队,会准备两个数据库：MySQL存核心交易这类规矩数据，Redis和Elasticsearch分别处理缓存和搜索，就像装修房子，你不能全屋要么只用螺丝钉要么只用胶水，关键位置得用对的连接件，去年我们试水区块链项目，那种链式数据结构用关系数据库存简直自虐，最后还是选了图数据库，这才叫对症下药。

所以真别纠结技术潮流,初创公司最该有个“数据库地图”——用户关系用图数据库，日志用时序数据库，商品目录用文档数据库，关键业务留在关系数据库，就像雷军说的“不要用战术的勤奋掩盖战略的懒惰”，拍板前先拿着业务原型画一画数据流向，比听100场技术分享会都实在。

（补充个冷知识：连Amazon最早也用Oracle，后来才自研DynamoDB，先用起来”比“用最潮的”更重要，船小好调头本来就是初创公司的特权不是？）