Datadog cut migration time from 45 min to 1 sec using Claude

Key Takeaways

• Datadog migrated a critical production system from FoundationDB to PostgreSQL using Claude and Cursor for test-driven refactoring
• Operations dropped from 45 minutes to about one second, with database costs reduced by 90%
• The success hinged on a strong test suite that served as a pass/fail criterion for every AI-generated change

Datadog's metrics pipeline had a problem. Their Stream Router API, built on an eventually consistent key-value store, was hitting transaction size limits. The worst operations took 45 minutes because of thousands of sequential database round trips. Engineers Arnold Wakim and team decided to migrate to PostgreSQL, and they used Claude and Cursor to do the heavy lifting.

The results: operations that once took 45 minutes now complete in about a second. Latencies dropped from hundreds of milliseconds to single digits. Storage shrank by up to 40x. Database costs fell 90%.

Why the original system broke down

Stream Router manages routing for Datadog's metrics pipeline. The original version used a key-value model that forced application code to reconstruct relationships between domain entities. The system would pull tens of thousands of entries into pod processes and essentially run relational database logic in-process, handling what foreign keys would normally enforce.

As the routing table grew, the KV database started hitting transaction size limits. The architecture couldn't scale. Datadog's engineers redesigned the schema to use PostgreSQL with proper foreign keys, replacing logic that previously lived in application code.

How Claude and Cursor fit into the refactoring process

The schema redesign was straightforward. Refactoring the entire codebase to use it was not. Wakim's team turned to AI, but not in the way you might expect. They didn't hand Claude autonomy over the codebase. Instead, they ran a systematic, test-driven process.

“We used Claude and Cursor to accelerate a systematic, test-driven refactoring process. They weren't generating code autonomously: For each method, we provided the old implementation, the new schema, and a failing test. The models would generate a first pass, and the tests told us whether it was correct.”

— Arnold Wakim, Datadog Engineer

Three elements made this work. First, strong code modularity. The new Stream Router implemented the same API on PostgreSQL, so nothing else in the system needed changes. Second, a comprehensive test suite that gave clear pass/fail criteria for every AI-generated change. Third, parallel infrastructure where two independent Stream Router instances ran side by side, handling the same requests while clients were routed between them via feature flags.

The three-phase migration

Phase one: Use Claude to describe the intent of each key function. This created a semantic map of what the code was supposed to do, separate from how it did it.

Phase two: Craft focused prompts to fix failing tests. Each prompt included the expected behavior plus context from phase one. Claude generated code, tests validated it, engineers reviewed the output.

Phase three: Deploy using a blue/green approach. The new PostgreSQL-backed Stream Router and the existing FoundationDB version ran in parallel. A dedicated validator service compared routing responses between them, alerting the team immediately if anything diverged.

Where AI fell short

Wakim was candid about the limitations. Higher-level prompts didn't work well. Claude generated correct but suboptimal queries, issuing far more database round trips than necessary.

Niche optimizations like batching, UNNEST tricks, and common table expressions required human input. Once engineers wrote the optimized versions, Claude could replicate the patterns in subsequent methods. But it didn't discover these patterns independently, even though they exist in the literature.

Token consumption was another issue. The team fed Claude full test output dumps instead of trimmed excerpts, and the iterative loop of test output, code context, and schema information burned through tokens quickly.

What other teams can take from this

Wakim's conclusion is direct: the strength of their test suite determined how much they could trust AI-generated code. Without that safety net, the migration would have been far riskier and slower.

The approach also required accepting AI's limitations upfront. Claude accelerated the grunt work but couldn't handle performance optimization. Engineers still had to teach it patterns, then watch it replicate them. That's not autonomy. It's a faster feedback loop.

For teams running similar migrations, the takeaway is clear: invest in tests first, keep prompts focused, and don't expect AI to optimize what it doesn't understand. The 90% cost reduction came from good engineering enabled by AI, not AI replacing engineering.

Frequently Asked Questions

What tools did Datadog use for their AI-assisted migration?

Datadog engineers used Claude (Anthropic's AI model) and Cursor (an AI-powered IDE) for test-driven refactoring of their Stream Router API.

How much did Datadog reduce database costs after the migration?

Database costs dropped by 90%, with storage becoming up to 40x smaller and operations that took 45 minutes completing in about one second.

Did Claude generate production-ready code automatically?

No. Claude generated first-pass code that had to pass existing tests. Engineers reviewed all output and manually wrote optimizations like batching and common table expressions.

What was the key factor that made Datadog's AI migration successful?

A comprehensive test suite that served as clear pass/fail criteria for every AI-generated change, allowing engineers to trust the output without manual verification of correctness.

Can this approach work for teams without extensive test coverage?

The approach depends heavily on test coverage. Without a strong test suite, there's no reliable way to validate AI-generated code, making the migration far riskier.

Source: InfoQ