使用PostgreSQL Babelfish将Sybase应用迁移至Aurora PostgreSQL的可行性问询

问题解答 #

• 是否有人实践过上述Sybase到PostgreSQL的迁移方案？
  有实际落地案例，主要集中在有大量遗留Sybase C/C++应用、无法承担全量业务代码改造成本的传统行业，部分金融、制造企业已经通过该方案完成了Sybase ASE到PostgreSQL的迁移，核心思路都是通过适配层转换协议而非修改业务代码。
• 该方案的落地可行性如何？
  可行性很高，适配难度较低：
  1. 语法层面：你当前用到的动态多语句T-SQL、多结果集返回、占位符传参都属于BabelFish 3.x及以上版本的高兼容特性，无复杂存储过程、自定义函数的前提下，SQL语法改造成本几乎为0。
  2. 链路层面：FreeTDS的CT库接口和Sybase原生OCS CT库的兼容性超过90%，仅需要将应用原来链接的Sybase CT库替换为FreeTDS的CT库，同时将FreeTDS配置文件中的tds version参数设置为7.4（BabelFish兼容的TDS版本）即可完成基础适配。仅需要针对业务用到的批量上传接口、错误码判断逻辑做极少量的FreeTDS层适配调整，改动量远低于业务代码改造。
• 是否必须使用freeTDS？Babelfish端口能否兼容发送TDS 5.X（或4.X）请求的客户端？
  必须使用FreeTDS作为协议转换层：BabelFish原生仅支持TDS 7.1及以上版本的协议（对应SQL Server 2000及之后的TDS标准），而Sybase客户端使用的TDS 5.X/4.X协议在报文结构、参数编码、交互逻辑上和TDS 7.X完全不兼容，无法直接连接BabelFish端口。FreeTDS是目前唯一成熟的、同时支持Sybase CT API实现、TDS 5.X解析和TDS 7.X转发的开源组件，没有可替代的低成本方案。
• 针对该迁移场景是否存在更优解决方案？
  如果严格限制仅能对应用或依赖库做少量修改，你当前设想的方案就是最优解。其他可选方案的改造成本都显著更高：
  1. 直接替换驱动为PostgreSQL官方libpq，需要将所有CT调用替换为libpq接口、所有T-SQL改写为PostgreSQL语法，涉及模块多的情况下成本极高；
  2. 商用Sybase迁移适配组件，虽然适配度更高，但需要支付商业授权费用，性价比远低于开源FreeTDS方案。

内容的提问来源于stack exchange，提问作者dash-o