Skip to main content

Case Study: How Deriv Automates Schema Migrations with Atlas

· 7 min read
Noa Rogoszinski
Noa Rogoszinski
DevRel Engineer

"Managing schema as code was the mindset we were looking for, and it was a perfect match with Atlas. It's able to support our database and others, which gives us flexibility going forward."

– Raunak Kathuria, VP of Engineering, Deriv

Company Background​

Deriv is one of the world's largest online brokers, and was recently named Best Fintech Broker (Global) at the 2026 Global Forex Awards. They offer CFDs and other derivatives on forex, stocks and indices, cryptocurrencies, commodities, and Derived Indices to millions of registered users across the globe.

The company runs on PostgreSQL across many schemas and databases, including multi-tenant setups, and relies on advanced features like views, functions, triggers, stored procedures, and row-level security. All of it operates under compliance requirements, including SOC 2, HIPAA, and PCI, that demand full audit trails on every change. Deriv's engineering teams also actively use AI agents in their development work.

A Single DBA as the Bottleneck​

Before Atlas, Deriv managed schema changes with homegrown tooling and SQL migration scripts that engineers and DBAs wrote by hand. Every change still had to pass through one DBA or lead engineer, which made that person a bottleneck as deploy volume grew. Engineers grew cautious about touching the schema at all, and enforcing consistent policies and standards across so many schemas and databases became a manual, error-prone job.

"Manually writing migration scripts made our development and code reviews slower, increased the risk of deployment errors, and made it much harder to consistently enforce our database standards across the team," said Mario Bryan Tan, Data Engineer Tech Lead at Deriv.

The manual process was also a security gap. With no automated linting or best-practice checks, the only thing standing between a destructive change, like a dropped column, and production was a reviewer catching it. As Raunak put it, "We were only storing our schema as code, not managing it."

The old scripts worked, but they demanded constant maintenance and manual effort from the DBA team just to keep up. "We wanted to automate the current process and automatically generate the schema changes," Raunak said.

Evaluating the Alternatives​

The opening came with a larger project: Deriv was rebuilding its legacy infrastructure from the ground up, and the team used this opportunity to evaluate migration tools. Given Deriv's compliance obligations, the must-haves were non-negotiable:

  • A declarative workflow combined with versioned migrations
  • GitHub integration and CI/CD automation
  • Linting and destructive-change prevention that stop unsafe changes before they ship
  • Every change auditable and version-controlled end-to-end
  • Minimal infrastructure to run, and a vendor that provides real support

Flyway, Liquibase, Sqitch, and Supabase migrations each fell short on at least one of these areas, and none could handle the full complexity of Deriv's database setup. For some, licensing costs and complexity counted against them as well.

Choosing Atlas​

Atlas's schema-as-code model was the click for Raunak. It matched the mindset the team was already looking for, and its support for PostgreSQL alongside other databases gave Deriv room to grow into new engines without switching platforms again.

For Mario, the decision came down to a working end-to-end test. "We were able to edit the declarative schema, use migrate diff to automatically generate versioned migration files, and leverage built-in linting to catch potential errors early," he said. "Integrating all of this directly into our GitHub Actions deployment pipeline clearly demonstrated Atlas's practical value for our team."

Integrating Atlas into the existing CI/CD pipeline was straightforward. Getting a platform of Deriv's size fully into production took more effort, and support is where the Atlas team stood out. "The support provided from the first day was amazing, and any bugs or issues we ran into were addressed immediately," Raunak said. Mario agreed: "During our onboarding phase, the Atlas team provided excellent support for our technical inquiries. They not only resolved our immediate issues but also helped us use the product more effectively, which solidified our decision to proceed with Atlas."

One Pipeline for Every Schema Change​

Today, developers at Deriv use Atlas's versioned migrations for every schema change. On every pull request, GitHub Actions runs Atlas's linting and safety checks, so destructive and risky changes get caught in CI before they reach production. "It flagged adding a foreign key without NOT VALID as risky," Raunak noted. If not caught, the team would have risked locking a live production table to perform a full table scan, causing an outage.

For a regulated broker, that pipeline doubles as security control. Every schema change is version-controlled, reviewed in a pull request, checked against destructive and risky patterns, and recorded for audit, without depending on one person to enforce it.

After deployment, Atlas Cloud's Schema Monitoring tracks the state of each environment, and the team uses its ERDs and visual diffs to see exactly what changed between migration versions.

Deriv's AI agents work through the same pipeline. "AI agents are able to work well with Atlas because they can read the declarative schemas to gain a complete, accurate picture of our database state," Mario said. From there, an agent generates the migration with migrate diff, runs the built-in linting and safety checks, and tests the result by deploying it to development and staging databases, so its changes pass the same checks as any engineer's.

The Outcome​

Atlas took schema migrations off the DBA team's plate entirely and put safe, auditable change-making directly in developers' hands.

  • Developers own schema changes. What Raunak calls the biggest win: developers no longer route every schema change through a single gatekeeper, nor do they avoid touching the schema out of fear of breaking something.
  • No more hand-written migrations or tooling upkeep. Atlas generates the versioned migration files, and the homegrown scripts that used to demand constant upkeep are gone. "We have not spent any time working on maintaining our schema migration tooling. It's all taken care of by Atlas," Raunak said.
  • Destructive changes get caught before production. Atlas's linting flags risky changes, like an unguarded foreign key addition, before they ship.
  • Standards are enforced automatically. Configurable checks and policies apply Deriv's database standards to every change, instead of relying on reviewers to remember them.
  • Faster reviews and deployments. Schema review used to mean waiting on the DBA team. Now the linter verifies migration safety up front, more engineers ship changes without a bottleneck, and incidents traced back to migrations have become rare.
  • Every change is visible after it ships. ERDs and visual diffs in Atlas Cloud make it straightforward to audit exactly what changed between migrations, across environments.
  • A workflow ready for AI agents. Agents handle schema changes end-to-end inside the same guardrails as the rest of the team. "Considering the workflows are properly set up and the tooling documentation is well-defined, AI agents can easily pick it up and start working with no major work required," Raunak said.

"Schema changes are now defined declaratively, and Atlas auto-generates and applies migration scripts, catching destructive changes before they land," Raunak said. "It's now the standardized migration product across teams, reliable enough that we've standardized it for our new architecture setup, with a good security posture."

"Atlas delivers what teams need to safely automate database deployments," Mario added. "As a company, their exceptional responsiveness and hands-on support gave us complete confidence in our decision to partner with them."

Getting Started​

Deriv replaced a single-DBA bottleneck and hand-written scripts with one pipeline where every schema change, from a developer or an AI agent, is generated, linted, reviewed, and recorded for audit. If your schema changes still wait on one person, or you need an auditable record of every change for SOC 2, HIPAA, or PCI, you can set up the same workflow: