信创的落地，ThingsBoard 将何去何从？
有些平台不是不够好，而是生不逢时——更准确地说，是技术栈与时代约束撞上了。
ThingsBoard 在全球物联网圈里并不陌生：设备接入、规则引擎、告警、看板、多租户，一整套「能上生产」的能力齐全。可在国内党政、央国企、关键行业信息化项目里，大家越来越常听到同一句话：
平台可以谈，库必须国产。
于是一个现实问题摆到桌上：信创加速落地，ThingsBoard 将何去何从？
这不是危言耸听，而是交付现场正在发生的选型压力。
一、政策时间到了，再也不是「可选项」
先把时间轴看清楚（行业内常被引用的节点，具体条文请以官方文件为准）：
要点可以概括成三句话：
- 党政领域：2026 年起，党政机关核心业务系统信创产品采购比例不低于 85%。
- 央国企：国资委相关要求指向 2027 年底前全面完成信息系统信创改造，并按季度报送进度。
- 政府采购：自 2026 年 1 月 1 日起，本国产品标准让「买国产」从行政倡导变成更常态的制度约束。
对做物联网平台的人来说，这意味着：
- 以前可以用「先上 PostgreSQL / Cassandra，以后再说」；
- 以后很多项目会在招标与验收环节直接卡：关系库、时序库是否在信创目录 / 是否满足国产化替代要求。
技术再漂亮，过不了合规门槛，就进不了机房。
二、ThingsBoard 的强，也卡在了技术栈上
ThingsBoard 的「强」大家都看得到：
- 设备与资产模型清晰
- 规则引擎足够灵活
- 看板、告警、RPC、OTA 等能力成体系
- 社区活跃，可私有化，适合做行业中台底座
但它的「痛」同样硬核——默认技术栈高度依赖海外开源组件，典型包括：
| 能力层 | 常见默认选择 | 国内信创项目里的尴尬 |
|---|---|---|
| 关系型业务库 | PostgreSQL | 许多项目要求国产关系库 |
| 海量时序 | Cassandra（或混合架构） | 运维重、人才少，且国产化叙事更难讲通 |
| 整体交付 | 开源组合拳 | 招标材料、等保/信创材料难「一次说圆」 |
于是出现一个令人扼腕的局面：
平台能力明明适合国内工业物联网与智慧城市场景，却因为数据库与中间件组合，在国内关键市场「走不进门」。
这不是 ThingsBoard「不行」，而是——
默认发行形态，没有为信创交付准备好答案。
三、好平台岂能埋没：我们选择「换底座，不换灵魂」
面对冲突，行业里常见三种态度：
- 放弃 ThingsBoard，换一套更「国产叙事友好」的平台——代价是重学、重做、重踩坑。
- 硬上原版栈，靠例外申请或灰度——在越来越硬的时间节点前，风险越来越大。
- 保留 ThingsBoard 的产品能力与工程体系，替换关键数据底座为国产组件——让业务能力继续用，合规路径说得通。
我们选第三条。
原因很简单：ThingsBoard 已经在全球和国内大量项目里证明了「物联网中台该长什么样」。丢掉它，等于丢掉成熟的设备模型、规则引擎与交付经验；留下它，但换上国产库，才是对客户真正负责的做法。
我们的路径可以一句话说清：
基于 ThingsBoard 4.3.x 进行定制化开发：用人大金仓（Kingbase）替换 PostgreSQL，用 TDengine 替换 Cassandra，作为时序存储。
这样，ThingsBoard 仍是那套熟悉的平台能力；交付现场却能回答信创问题：库是国产的，架构是可说明的，演进是可持续的。
四、为什么选人大金仓替换 PostgreSQL？
关系库是 ThingsBoard 的「业务中枢」：租户、用户、设备、规则链配置、看板元数据……大量结构化数据都在这里。
选择 人大金仓，核心判断不是口号，而是工程现实：
1. 根子上贴近 PostgreSQL 生态
人大金仓（KingbaseES）与 PostgreSQL 渊源深厚。业内常说其兼容路线可追溯到 PostgreSQL 9.6 一脉——对长期基于 PG 开发与运维的团队而言，这意味着：
- SQL 习惯、索引思路、事务模型迁移成本相对可控
- 许多「PG 思维」的排查方法仍然有效
- 适配 ThingsBoard 这类「原本就以 PostgreSQL 为第一公民」的系统，路径比从零适配完全异构库更短
简单讲：不是硬把两套完全不同的世界焊在一起，而是站在「本就相近」的底座上做国产化落地。
2. 信创项目里「讲得清楚、验得过去」
在党政、央国企场景，关系库往往是审计与材料里最先被问到的一环。人大金仓作为国内主流国产数据库之一，更便于进入：
- 方案设计与招标应答
- 部署与运维规范编写
- 与信创整体方案（OS、中间件、其他国产组件）对齐
3. 对 ThingsBoard 定制化开发更友好
我们基于 ThingsBoard 4.3.x 做适配与定制，正是看中这一代在工程上已经成熟：模块边界清晰、规则与存储路径可改、适合作为长期维护的产品基线。把关系库切到金仓，本质是「保留平台灵魂，更换合规底座」。
五、为什么时序库选择 TDengine？
物联网平台的另一半灵魂是时序：高频遥测、历史曲线、聚合统计、告警判定依赖……原版路线里 Cassandra 很常见，但在国内交付里，它常常带来三重压力：
- 运维复杂度高（集群、修复、容量规划门槛不低）
- 人才与经验稀缺（现场能稳住 Cassandra 的人并不多）
- 国产化叙事弱（越来越多项目直接问：有没有国内时序方案？）
TDengine 的选择逻辑同样务实：
- 国产时序数据库，更贴合信创与行业项目表述
- 面向物联网 / 工业监测场景设计，写入与查询路径清晰
- 对「设备多、测点多、写多读聚合」的画像更友好
- 便于与 ThingsBoard 的遥测存储策略做工程化对接
我们不是为了「换一个时髦名字」，而是为了让现场运维、采购合规、性能目标三件事能同时成立。
六、基于 ThingsBoard 4.3.x：为什么卡这个版本？
定制化开发必须选一条可长期维护的基线。我们锚定 4.3.x，主要出于三点：
- 生产可用：该系列在社区与交付侧已有足够实践沉淀
- 改造空间明确：关系库、时序存储、规则与部署形态都有清晰切入点
- 与国内交付节奏匹配：信创改造要的是「能上线、能验收、能运维」，不是追每一个最新小版本号
版本可以跟随演进，但底座策略要先立住：
金仓扛业务库，TDengine 扛时序，ThingsBoard 扛物联网中台能力。
七、这对客户意味着什么？
如果你正在做这类项目，也许正卡在同样的问题上：
- 业务团队认 ThingsBoard 的能力与交互
- 信息管理 / 招标 / 安全认信创清单
- 两边互相看不上对方的「默认答案」
我们的信创路径，就是帮你把这两边缝合起来：
| 你要什么 | 我们怎么给 |
|---|---|
| 熟悉的物联网平台能力 | 继续基于 ThingsBoard 4.3.x 定制化开发 |
| 国产关系库 | 人大金仓替换 PostgreSQL |
| 国产 / 可落地的时序方案 | TDengine 替换 Cassandra |
| 可私有化交付 | 按项目做部署、权限、看板与规则落地 |
| 可说明的方案材料 | 技术选型与替换路径写清楚，方便应答与验收 |
相关产品能力也可在官网查看：ThingsBoard 信创支持。
八、写在最后：何去何从，答案其实很明确
信创不是否定开源，也不是否定优秀的国际物联网平台。
它否定的是——在关键系统里，继续对「不可控的默认底座」无动于衷。
ThingsBoard 不该被埋没。
它该做的，是换上一双能走进国内机房的鞋子。
所以我们的答案是：
不抛弃 ThingsBoard 的平台能力，而用人大金仓 + TDengine 重建信创可交付的数据底座；以 4.3.x 为基线做定制化开发，让好平台继续服务中国现场。
政策时间点已经很近了。
与其临近招标再临时换栈，不如现在就把「能力」和「合规」放在同一条路上。
如果你正在推进党政、央国企或行业信创场景下的物联网平台选型，欢迎交流：我们可以从现状评估、替换路径、到私有化上线，把事情一次做清楚。
— HikariThings
让物联网交付更简单。