---
格式版本: 2
标题: "Using Antigravity CLI to streamline dual-write database migration"
原文链接: "https://cloud.google.com/blog/topics/developers-practitioners/using-antigravity-cli-to-streamline-dual-write-database-migration"
发布日期: "2026-09-05"
发布时间校准状态: "found"
发布时间需复核: "否"
发布时间来源: "rule:configured_publication_date_rule"
发布时间证据: "google-cloud-blog-date-div html:original: September 5, 2026"
发布时间校准原因: "信源发布日期识别规则直接确认发布时间"
发布时间校准置信度: "high"
发布时间候选数量: 1
发布时间严格候选数量: 1
发布时间原页读取状态: "source template page reused from URL open"
发布时间未找到原因: ""
发布时间校准时间: "2026-09-06T09:30:51+08:00"
发布时间仲裁状态: "skipped"
发布时间仲裁尝试次数: 0
发布时间仲裁耗时毫秒: 0
发现时间: "2026-09-06T09:29:36+08:00"
入库时间: "2026-09-06T01:31:02.406Z"
来源平台: "固定入口"
搜索渠道: "fixed_url"
搜索词: "https://cloud.google.com/blog/"
匹配关键词:
  - "throughput"
  - "AI"
相关厂家:
  - "Google"
相关专家:
  []
内容类型: "网页"
抓取工具: "Free Fetch + Defuddle"
清洗工具: "Defuddle Markdown + Defuddle/Readability 正文提取"
原始附件:
  []
AI优质: "否"
AI打分: 30
AI分档: "非优质"
AI质检状态: "不通过"
AI打分理由: "正文主线是Google财务工程团队使用Antigravity CLI自动重构30多个DAO，以双写、回填和数据一致性校验迁移至Spanner，属于数据库迁移实践，与超节点、AI机架及其关键部件无关。来源为Google Cloud官方技术博客，权威性较高；知识库未见该迁移事件，但未命中不能证明首次发布。新增事实仅包括自动化重构流程、三阶段迁移方法及尚处于预生产准备阶段的内部实践，没有机架级新产品、标准、工程指标或商业部署信号。当前正文还在代码模式展开前截断。命中教程/运维实践及主题弱相关否决项。"
AI质检模型: "gpt-5.6-sol"
AI质检时间: "2026-09-07T07:40:14+08:00"
AI主题相关性: 0
AI来源权威性: 14
AI新颖性: 6
AI技术细节: 4
AI商业部署信号: 0
AI完整性: 6
AI评分提示词版本: "v17-精简生产版"
AI评分提示词SHA256: "48fb9777f386026761b4873eaff30807694fb11e9b352d7c69bf2dfde750cc7d"
AI评分知识库版本: "knowledge_base_v1-20260819+runtime.82"
AI评分知识库SHA256: "1ec61c5fd6e83ae24d0c32a5ecbe0af92c4addffb57cfe99140a5309013f395c"
AI评分知识库检索词: "[\"Google\",\"https://cloud.google.com/blog/\",\"CLI\",\"DAOs\",\"DAO\",\"API\",\"RPC\"]"
AI评分知识库命中: "[{\"id\":\"runtime-bf4039a0342d37545e9459a2\",\"title\":\"Most Neoclouds Suck At Security\",\"sourceType\":\"ai_excellent_article\",\"time\":\"2026-08-30\",\"matchedTerms\":[\"Google\",\"CLI\",\"API\"],\"rank\":-10.178556655764739},{\"id\":\"runtime-3dcabc270e938e0c3b6d5245\",\"title\":\"Nvidia wants to bypass the CPU with an open-source AI storage overhaul\",\"sourceType\":\"ai_excellent_article\",\"time\":\"2026-08-06\",\"matchedTerms\":[\"Google\",\"API\"],\"rank\":-7.81500143105408},{\"id\":\"runtime-5581f72bc66fda8e6c6bf711\",\"title\":\"Advancing Standards-Based AI Fabric RAS Through COSMOS Integration\",\"sourceType\":\"ai_excellent_article\",\"time\":\"2026-08-10\",\"matchedTerms\":[\"API\"],\"rank\":-5.516635949981684},{\"id\":\"runtime-569639751a0dbe7ef3ffccc5\",\"title\":\"[2608.17503] Predict Before Replay: Joint FEC and Flight Control for Reliable Scale-Up Links\",\"sourceType\":\"ai_excellent_article\",\"time\":\"2026-08-18\",\"matchedTerms\":[\"Google\",\"API\"],\"rank\":-5.5019141149593676},{\"id\":\"historical-jan-apr-02\",\"title\":\"二、Google Cloud Next '26：AI Hypercomputer 与第八代 TPU 发布\",\"sourceType\":\"curated_item\",\"time\":\"2026-01_to_2026-04\",\"matchedTerms\":[\"Google\"],\"rank\":-4.9894712678632045}]"
AI摘要: "Google Finance Engineering 团队为迁移到 Spanner，使用 Antigravity CLI 的 headless 模式构建自动化重构管道，替代手动改写 30 多个 DAO 的双写逻辑。"
AI摘要模型: "ali-deepseek-v4-flash"
AI摘要时间: "2026-09-06T23:45:09.549Z"
采集批次: "2026年9月6日9点29分24秒"
采集批次ID: "20260906-092924-951"
去重键: "https://cloud.google.com/blog/topics/developers-practitioners/using-antigravity-cli-to-streamline-dual-write-database-migration"
---

Developers & Practitioners

## Spanner migrations: Automating dual-write with Antigravity CLI for minimal disruption

##### Sachin Mathapati

Application Engineer

##### Try Gemini Enterprise today

The front door to AI in the workplace

[Try now](https://business.gemini.google/?utm_source=cloud.google.com/blog&utm_medium=et&utm_campaign=FY26-Q2-GLOBAL-GLO27877-physicalevent-er-next26-mc-105752)

When Google's Finance Engineering team needed to modernize their legacy data layer, they chose [Spanner](https://cloud.google.com/spanner?e=48754805), a globally distributed, strongly consistent, multi-model database with high availability capabilities. But migrating to Spanner without taking production services offline was a daunting engineering challenge: As the internal team responsible for the application, we needed to manually rewrite dual-write logic across dozens of Data Access Objects (DAOs), a process that is slow and prone to human error. Further, doing so without disruption would have required implementing multi-phase dual-write architectures across every DAO in our codebase.

To solve this, we took an alternative approach: We built an automated refactoring pipeline powered by Antigravity CLI in headless mode. This helped us accelerate our migration velocity significantly while maintaining strict data parity in our staging environments as we prepare for production.

### The challenge: Anatomy of a dual-write migration

When migrating high-throughput production services where financial accuracy is essential, simple cutover scripts do not work. You must verify that both the legacy datastore and Spanner receive identical writes simultaneously until all the historical data backfills and verifications are complete.

We structured our migration across three distinct phases:

- **Historical backfill:** Copying existing historical records to Spanner while maintaining referential integrity.
- **Dual-write / dual-read implementation:** Modifying every DAO to write mutations to both the primary store and Cloud Spanner in parallel during the migration window.
- **Automated API verification and parity checking:** Intercepting RPC traffic and verifying end-to-end that every write lands with byte-for-byte equivalence across both stores.

The architectural pattern is clean, but at our scale, we began to encounter friction. That’s because each DAO requires:

- A dedicated MutationConverter class mapping complex domain models to Spanner schema columns
- Dual-write branch handling and rollback or error-reporting logic
- A suite of unit tests verifying both primary and Spanner writes using fake time sources and test doubles (FakeTimeSource)

Performing these identical, high-precision code changes across 30+ DAOs by hand would have taken months of engineering time.

### The solution: Standardized mutation converter patterns

To verify that our automation pipeline could reliably generate clean code, we first standardized our DAO refactoring pattern around a decoupled MutationConverter interface.

Instead of embedding raw Spanner table names and column assignments directly inside core DAO business logic, we isolate Spanner schema translation into dedicated converter units:
