Case Study: How EliseAI Democratized Schema Management Across 50 Databases

Company Background

EliseAI transforms complex housing and healthcare systems, helping property managers and healthcare providers handle leasing, maintenance, and resident engagement. By deeply integrating into workflows and automating operations, it cuts costs for all parties. EliseAI powers 1 in 6 rental apartment units in the U.S., processing hundreds of thousands of messages and thousands of voice calls per day.

Four Admins for Fifty Databases

A service at this scale is sure to result in vast amounts of data. Ken Koch, Director of Engineering, explained that their team organizes it all by function. "At this point we probably have 50 different databases that we vertically sharded to handle specific purposes," Ken said. Each database is tied to the microservice that owns it — CRM, maintenance scheduling, resident charges, and more — with event-driven functions running on AWS.

Schema changes did not keep pace with that architecture. Following industry standards, production database access was limited to a handful of administrators to minimize human error and ensure compliance. While this "gatekeeper model" reduced the risk of conflicting or careless changes, it quickly became a persistent bottleneck as the organization scaled.

“Four of us had admin-level schema access, and if anyone wanted to make any schema changes, they would send those through to us. It doesn't scale very well," Ken said. Every structural change competed for the same small pool of people, so when an engineer needed a column added or an index created, they simply had to send the request and wait for an admin to execute it by hand.

A newer pressure compounded the problem. As the team leaned into AI-assisted development, coding tools needed an accurate, up-to-date view of the schema to generate useful changes. A workflow that kept schema changes in the hands of four administrators, or let production drift out of sync with the codebase, worked directly against that goal.

Searching for a Solution

The team turned to existing tools, such as Alembic, to introduce more structure into the schema management process. "We introduced Alembic as a solution and ran into versioning issues or conflicts constantly, which added a lot of friction to the workflow," Ken explained. Engineers who should have been iterating on the product were instead untangling migration history.

They began looking for a solution that would give engineers more agency over schema changes, but versioned workflows that required maintaining parallel migration histories across dozens of databases were not enough.

Several requirements shaped what they were looking for. "Admins should be able to make manual database changes when needed. They cannot be blocked by a tool if there are critical issues," Ken said. They also needed an additive workflow where the declared schema drove what got created or extended without automatically reverting manual production adjustments.

Additionally, with the team investing in AI-assisted development, they needed the schema to live in version control where both engineers and tooling could read it. "I want the AI to be schema aware. It should be able to propose updates to our database schema and know exactly what's going on so that we can make the best changes," Ken said.

Choosing Atlas

After evaluating several options, Ken's team came across Atlas, a database schema-as-code tool that treats the desired schema state as the source of truth and plans the minimal set of changes to reach it.

"I wanted something where I define what my schema should look like," Ken said. Atlas offered that declarative model — a source of truth in code that describes the desired end state, with the tool planning the diff.

The team also wanted their schema workflow to fit naturally into GitHub, where the rest of their development process already lived. They used Atlas-Action to tailor their schema workflow to the sequence they already follow: propose a schema change, validate and apply it in the appropriate environment, and only then merge. "It felt collaborative," Ken said of working with the Atlas team. "I really appreciate all the effort and help you all provided us on it, too."

The Outcome

Choosing Atlas gave EliseAI a declarative way to manage schema across its sharded database fleet and a direct path out of the gatekeeper bottleneck.

To make schema changes, an engineer creates a branch, updates the schema files, and opens a pull request. Atlas Actions generate the migration, lint the proposed changes, and report results on the PR. Engineers receive feedback on potential risks and can iterate without waiting for an administrator to run statements by hand. The team also added checksum validation in GitHub Actions to catch race conditions when multiple schema pull requests are open at once.

In addition to unblocking the workflow, Ken noted other benefits of using Atlas:

• Democratized Database Changes. Before Atlas, four administrators owned every structural change across the database fleet. Today, between 50 and 60 engineers contribute schema changes through the same pull request workflow used for application code. "Everyone is adding database changes and making data changes now," Ken said.
• Safety and Stability. Since Atlas went into production use, the team has not hit the locking or migration failures that previously made engineers hesitate to propose changes. "We haven't had any database locking or migration issues since we've rolled out Atlas," he added.
• Self-Service Conflict Resolution. With an additive, declarative workflow, engineers gained the confidence to manage their own changes rather than escalating every collision. "Once they understand what Atlas is doing, they're able to easily fix schema conflicts that other people have introduced, rebase, and unblock themselves," Ken explained.
• Stronger Testing Practices. EliseAI moved toward integration-level testing with real database schemas spun up for each run, rather than relying on unit tests alone to catch structural mismatches.

Getting Started

By managing your schema as code and configuring Atlas-Actions in CI/CD, you can automate migration creation and review so schema changes no longer depend on a handful of people with admin-level schema access.

If your team is struggling with a gatekeeper model for schema changes, or if versioned migration tools keep stalling your workflow the way they did for EliseAI, Atlas could be the solution for you.