使用The Graph协议创建的subgraph能否与Rails应用共用同一PostgreSQL数据库

1. 是否可以和Rails/Node.js应用共用同一个PostgreSQL？ #

官方没有强制要求subgraph必须使用专属PostgreSQL实例，但生产环境极度不推荐共用同一个库，核心原因如下：

• The Graph索引节点会自动创建、修改大量专属表、索引、自定义枚举类型，和业务库共用时极易出现命名冲突，严重时会导致业务数据被误覆盖或删除。
• 区块同步高峰阶段，The Graph会发起高频批量写入操作，占满数据库IO、CPU、内存资源，直接导致业务应用的读写请求卡顿、超时甚至服务雪崩。
• The Graph的数据库schema和节点版本强绑定，节点升级时会自动执行数据库迁移脚本，共用库大概率会出现迁移冲突，最终导致两边服务同时不可用。

2. 专属数据库+Rails多数据源读取是不是最优方案？ #

是目前生产环境的主流最优方案，优势非常明确：

• 资源完全隔离，The Graph的同步操作完全不会影响业务库的稳定性
• Rails原生支持多数据源配置，接入成本极低，仅需两步即可完成配置：
  1. 在config/database.yml中新增subgraph数据库的连接配置
  2. 创建专属的抽象基类绑定subgraph数据源，后续所有查询subgraph的模型都继承该类即可，示例代码如下：

  # app/models/subgraph_base.rb
  class SubgraphBase < ApplicationRecord
    self.abstract_class = true
    # 仅需要读取权限的话可以只配置reading，不需要配置writing
    connects_to database: { reading: :subgraph }
  end
  

• 可以灵活控制权限：给Rails访问subgraph的数据库账号仅授予SELECT权限，完全避免业务代码误修改subgraph的同步数据，保障索引节点的正常运行。
• 架构扩展性更强：后续可以单独给subgraph数据库扩展只读实例、增加查询缓存层，完全不需要调整业务库的现有架构。

3. 生产环境使用注意事项 #

• 对subgraph的高频查询建议增加Redis等缓存层，既降低subgraph数据库的查询压力，也能提升业务接口的响应速度
• 升级The Graph节点版本前，提前校验schema变更内容，避免查询语句出现兼容性错误
• 不要在subgraph数据库中创建任何业务相关的表、索引，避免和The Graph的自动迁移逻辑冲突

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