PERN栈使用AWS RDS托管数据库时是否仍需后端服务、能否前端直连RDS？

必须保留Express后端作为RDS与前端之间的中间层，完全不存在前端直连RDS、省掉全部服务端代码的可行路径。
你对架构调整的顾虑，本质是对不同协议、不同技术栈的职责边界存在混淆，两种选型方向的可行性可以直接对照技术限制逐一拆解。

为什么不能让前端直连RDS #

• 协议层面根本不通：RDS使用Postgres原生TCP二进制协议通信，运行在浏览器环境的前端代码受安全沙箱限制，根本无法发起自定义TCP端口的原始连接，浏览器只会处理HTTP/HTTPS、WebSocket等标准Web协议，连建立连接的第一步都完成不了。哪怕你找第三方工具把Postgres协议转成HTTP协议给前端调用，这个工具本身就是一个独立部署的后端服务，本质上还是没有省掉服务端层，只是换了个实现形式而已。
• 安全风险完全不可控：如果硬要在前端嵌入RDS的连接凭证，所有写在前端代码里的密钥、连接串都可以通过浏览器开发者工具直接被用户提取，拿到凭证后任何人都可以直接操作你的RDS实例，执行删库、导出全量数据、篡改业务数据等操作，没有任何权限边界可言。
• 连接数很快会打满：RDS的最大可承载连接数和实例规格直接绑定，前端每个用户会话如果直连数据库，单是几百个活跃用户就能把小规格RDS的连接数耗尽，生产环境本来就是靠后端维护统一的数据库连接池，做连接复用、流量削峰，才能把实际数据库连接数控制在RDS的承载范围内。
• 原有业务逻辑完全失效：你之前在Express路由层写的权限校验、参数合法性检查、数据格式转换等逻辑，如果改成直连数据库，要么需要把全量逻辑搬到前端公开给用户（用户可以通过篡改前端代码绕过所有校验），要么这些逻辑直接缺失，业务规则形同虚设。

架构调整的落地方式 #

这次从自建Postgres迁移到AWS RDS的改动量极小，完全可以对齐你之前已经跑通的开发流程，不需要推翻原有代码：

• 仅需要替换后端代码里的数据库连接配置：把原有指向本地Postgres的host、端口、账号、密码，替换为AWS RDS控制台提供的对应连接参数，原来基于pg库写的连接池、所有Express路由、SQL查询逻辑几乎不需要修改。
• 最终落地的架构就是 RDS <-> Express后端 <-> 前端，和你之前的后端（带本地PG）<->前端的交互逻辑完全一致，只是把自建数据库的运维工作（备份、版本升级、故障恢复）托管给AWS处理。
• 上线前只需要做两项安全和稳定性校验：
  • 配置RDS安全组时，仅对后端服务器所在的内网IP开放5432端口的访问权限，绝对不要把RDS端口开放给公网0.0.0.0网段
  • 后端连接池的最大连接数配置要和当前RDS实例规格的最大连接数匹配，避免连接打满影响数据库稳定性

内容的提问来源于stack exchange，提问作者Zegna