想象一家餐厅把“厨房怎么装修”和“每道菜怎么做”写进同一本施工手册：眼下省事，改菜单时却可能牵动整套工程流程。Reddit 上一位新任 BI 经理遇到类似问题：团队用 AWS CDK——用代码描述和部署云资源的工具——管理 BI Postgres 数据仓库里的视图和物化视图，CTO 因现有方案能运行，不愿再引入 dbt 和 Airflow。
分界点不只是能不能自动部署，而是谁负责变化。数据库视图是保存下来的查询定义，通常用于稳定报表口径；dbt 会把这类 SQL 组织成带依赖、测试和文档的数据模型，更贴近“业务数据怎样算”。CDK 原本更擅长数据库实例、网络和权限。把视图交给它，相当于让基础设施发布同时承担数据模型迁移。
帖子还暴露了更具体的摩擦：普通视图可经 GitHub 自动部署，物化视图却要手动删除再创建。后者会实际保存查询结果，还牵涉刷新、重建成本和可用性。是否应换成 dbt 加 Airflow，材料没有给出结论；尤其团队还计划迁往 Snowflake 或 Redshift，真正该先厘清的是对象归谁维护、怎样迁移和验证，而不是单纯比较工具多少。