Case Study: How Yad2 Simplified Schema Management with Atlas

Company Background

Yad2 is the most popular online marketplace in Israel for buying and selling second-hand items. Since launching in 2005, Yad2 has offered an organized platform for the sale of various goods, including vehicles, housing, rentals, furniture, electronics, and more. With millions of users and listings, Yad2 handles a significant amount of data and requires a robust database management system.

The Bottleneck: All Paths Lead to the DBA

Initially, all developers at Yad2 had permission to run DDL (Data Definition Language) commands, allowing each of them to alter the structure of the production database. However, as the team grew, engineers would run into conflicts and inconsistencies caused by parallel work. Developers would often overwrite each other's changes or introduce locks on the database, causing production issues. Requiring engineers to document their changes in JIRA or Slack was helpful, but it still proved difficult to keep track of everything that was happening.

To improve the reliability of schema changes, Yad2 brought on a DBA, Yoni Sade, to take the reins, and restricted the developers' permissions to DML (Data Manipulation Language) commands. This change meant that they could no longer make schema changes, leaving those tasks to the new DBA.

The motivation for this change was sound: by limiting schema changes to fewer, more experienced DBAs, they could prevent migration conflicts and ensure the integrity of the database structure. However, putting this limitation on the development environment created a significant bottleneck — every time a developer needed to make a schema change, they had to go through the DBA, slowing down the development process considerably.

Yad2 has a very complex and interconnected schema containing thousands of objects, so each change needs to be made very carefully. Even for a seasoned DBA, this process takes a lot of time and attention.

Searching for a Solution

Yoni began looking for a solution that would allow the team to have more agency over schema changes without risking the infrastructure's integrity. The team tested schema migration tools out on the market, but versioned workflows that still required manual planning without guaranteeing consistency between environments were not enough.

Ultimately, they were looking for a tool similar to Terraform, which they were already using for infrastructure as code. "We wanted to have a source of truth in code or a file-formatted representation of our schemas. Since we use Terraform, we wanted something similar that everybody would already feel comfortable with," Yoni said.

Choosing Atlas

After evaluating several options, Yoni's team came across Atlas, a database schema as code tool that implements concepts similar to Terraform but for databases. Not only did Atlas fit the description they were searching for, they also discovered more features that simplified the integration of Atlas into their existing workflow.

"We have many GitHub repositories, so integration with GitHub was also an important consideration," Yoni explained. Atlas's GitHub integration is a convenient way for teams to host their schema definition files on a shared platform, and there are Atlas Actions that can be used to automate the proposal, linting, and approval of schema changes on GitHub's platform. "I found Atlas's GitHub support very natural for us to use."

The Outcome

Choosing Atlas not only gave Yad2 a familiar way to manage their database schema as code, but it also provided a direct and easy to implement solution to their bottleneck by integrating with their already-existing GitHub repositories.

To make schema changes, a developer now creates a new branch in GitHub, makes the necessary changes to the schema files, and opens a pull request (PR). This automatically triggers Atlas Actions that write a migration based on the suggested changes, lint the proposed migration, and report the results in a comment on the PR.

The developer is now receiving direct feedback from Atlas about any potential risks from these changes and can work on them without needing to wait for the DBA. Moreover, the DBA gets a detailed account of the schema changes and can automatically apply them to production by simply merging the PR.

In addition to Atlas being a direct solution to their bottleneck, Yoni also noted other benefits of using Atlas:

• Improved Communication. With schema changes proposed through pull requests, there is a clear record of what changes were made, why they were made, and who made them without relying on manual documentation.
• Compliant Schema Changes. By using custom schema policies with the migrate/lint action, any proposed change that doesn't adhere to the team's schema policy is flagged in the CI process.
• Tracking Across Environments. The Atlas Cloud UI provides users with an Entity Relationship Diagram (ERD) to visualize their schemas and schema changes, as well as drift detection to alert the team of any inconsistencies between the developement and production environments.

Getting Started

By managing your schema as code, using custom schema policy, and configuring Atlas Actions in CI/CD, you can automate migration creation and review so the DBA is left with only a final review and approval.

If your team is struggling with the bottleneck of many developers relying on fewer DBAs to deploy schema changes like Yad2 was, Atlas could be the solution for you.

→ Start with the quickstart

→ Join our Discord

→ And begin managing your schemas as code.