稚一手里维护着Nacos 2.3.0的生产集群，公司统一数据库是PostgreSQL，但为了一个配置中心单独起一套MySQL，运维那边一百个不乐意。Nacos从2.2.0开始引入了数据源插件机制，理论上不止能接MySQL，PostgreSQL、达梦这类数据库都能通过插件接进去。我花了两天时间把Nacos 2.3.0从默认存储切到了PostgreSQL（下文简称PG），踩了几个不大不小的坑，把完整过程和原理整理出来。
这篇适合两类人：一是公司已经在用PG、不想再为Nacos维护一套MySQL的运维和开发，二是想搞明白Nacos数据源插件到底怎么工作、打算接其他数据库（比如达梦、openGauss）的读者。我不只会告诉你步骤，还会把“为什么Nacos不能只加个JDBC驱动就完事”讲透，因为这才是接其他数据库时最用得上的部分。
1. 换存储之前，先想清楚要不要折腾
1.1 Nacos默认存储的三个痛点
Nacos单机版默认用的是内嵌Derby，启动不需要任何外部依赖，开箱即用，非常适合刚接触时的demo。但拿到生产环境，Derby的坑就藏不住了。首先是数据隔离问题，每个Nacos节点都会在自己本地生成一份Derby数据文件，多个节点之间互相不知道对方写了什么。你这台节点上发布了一条配置，另一台节点的客户端拿到的还是旧值，集群越扩越乱。
其次，Derby的数据文件跟Nacos安装目录绑定，升级、迁移、重建节点的时候，很容易把配置数据弄丢。虽然Derby本身会落盘，但这份数据既不透明也不好备份，真要恢复数据，你连个趁手的SQL工具都难找。第三点，Nacos官方对Derby的定位就是“单机体验用”，集群部署时官方文档写得很清楚，必须换成外部数据库。很多团队一开始图省事，用Derby跑了好几个月，等配置量上来、节点一扩容，才回头补课。
1.2 为什么我选了PostgreSQL而不是继续用MySQL
我们公司的数据库基线就是PostgreSQL，云上实例、备份、监控、账号体系都是围绕PG搭好的。如果让Nacos用MySQL，等于为一个配置中心单独引入一套异构数据库，运维要额外维护实例、监控、备份，出了问题还得两套数据库的知识都懂，这种隐性成本远大于Nacos本身那点存储开销。
另外，PostgreSQL的许可协议比MySQL的商业授权边界更清晰，在合规要求严格的公司里，用PG能省掉不少商务层面的扯皮。容量上，Nacos存的主要是配置文本、历史版本、用户权限，数据量通常不会很大，PG在这个量级上性能没有任何压力。
1.3 什么情况下不建议换
如果你只是单机跑个测试环境，或者公司数据库就是MySQL一统天下，那就老老实实待着别折腾。Nacos配置文件动辄几百上千条，存储层稳定性比数据库本身的特性重要得多。换数据库这件事，本质上是“现有基础设施适配”的问题，不是“哪个数据库更牛”的问题。如果团队对PG不熟，出问题排查成本反而升高。
提示：Nacos对存储的要求很朴素——能存、能查、能事务、能备份。选哪个数据库，优先看公司已有的运维体系和团队熟悉度，别为了“尝鲜”去动生产配置中心。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 版本选型和前置准备，先把环境这条线捋直
2.1 版本匹配别拍脑袋
Nacos 2.3.0是2.x系列里比较稳的版本，数据源插件机制已经成熟。关键要确认的是你手里的PostgreSQL插件和Nacos大版本匹配。社区里有些插件项目只适配到2.2.x，硬拿到2.3.0上可能因为SPI接口变化加载不出来。我实际用的组合是这样：
| 组件 | 推荐版本 | 备注 |
|---|---|---|
| Nacos Server | 2.3.0 | 从2.2.0开始才支持数据源插件，2.3.0机制完善 |
| PostgreSQL | 12 ~ 15 | 主流版本都行，建议和公司现网大版本保持一致 |
| PG JDBC驱动 | 42.5.x及以上 | 插件一般会带，自己补驱动时注意和PG版本兼容 |
| PG数据源插件 | 社区版1.x | 选择明确标注适配Nacos 2.3.x的版本 |
PostgreSQL这边不需要额外装什么扩展，Nacos用到的都是基础功能。JDK版本我建议用8或者11，Nacos 2.3.0官方对17的支持虽然有了，但生产环境没必要冒险。数据库连接这块，插件内部用的是HikariCP连接池，我们不需要引入额外的连接池依赖。