Case Study: How Darkhorse Emergency Tamed Complex PostgreSQL Schemas with Atlas

"When I came across Atlas and saw it described as Terraform for your database, it immediately resonated. That’s exactly what we needed. Just like Terraform solved our AWS problems, we needed something to bring that same level of control to our data."

– Maciej Bukczynski, Director of Technology, Darkhorse Emergency

Company Background

Darkhorse Emergency is a SaaS decision analytics platform for public safety services, primarily fire departments, that uses data and predictive analytics to optimize operations and resource allocation. Their platform allows for decisions to be simulated and assessed before being made, creating more transparency amongst public service teams and those that depend on them.

The Bottleneck: Evolving a Logic-Heavy Postgres Schema

"For us PostgreSQL isn't just storage. It's the core of our business logic. "

Darkhorse Emergency's platform is built on a complex PostgreSQL database that serves as the backbone for their application. It is an elaborate system that processes many types of data, including 911 calls, census reports, and other public data sources.

By maintaining a carefully designed chain of views, functions, custom types, and triggers, the team is able to offload complex calculations and logic to the database. This ensures that their application can efficiently handle the demands of public safety services. "For us PostgreSQL isn't just storage. It's the core of our business logic," said Maciej Bukczynski, Director of Technology at Darkhorse Emergency.

However, this complexity presents a significant challenge when it comes to evolving the database schema. With so much happening within the database itself, the team very quickly ran into the limitations that come with common migration tools. "For example, we might have a view that feeds into 50 other views; if we want to make a change to that, we need to carefully recreate dependencies and ensure that everything remains consistent", Bukczynski explained.

The team initially tried to use classic migration tools like Flyway and Liquibase, but found that manually planning and applying migrations in such an intricate system was not only time-consuming but error-prone.

Looking for automation

The team at Darkhorse Emergency quickly realized that they needed a more automated solution to manage their database schema changes and set out to find a tool that could handle the complexity of their PostgreSQL database.

Bukczynski's team evaluated several tools that promised to automate the planning of complex schema changes, but quickly ran into roadblocks. "With any other tool that I was familiar with," he explained, "you were either doing everything by hand or you were trying to automate everything and inevitably running into incompatibilities."

These limitations weren't minor. "Things would get recreated out of order, things would go missing, some tools didn't support custom enum types... whatever it was, you'd just be in edge case after edge case," he said.

Ultimately, the tooling became a blocker rather than an enabler: "This tool is in the middle, preventing you from using that feature."

The "Hybrid" Approach

The team couldn't find a program that supported the breadth of features they were working with. Instead, they developed their own "hybrid" approach, using classic migrations to manage the tables with a long, carefully crafted destroy-and-rebuild script for everything else.

"That actually worked quite well for a number of years, but it's not a very safe approach," Bukczynski said. It could easily introduce drift if an object is left out of the migration script or downtime if the migration fails when trying to recreate the whole schema. Since the statements were being applied by running a single migration script, rolling back to find the source of the failure was not an option.

Additionally, this approach is not accessible beyond the few developers who have been working on the database from the beginning, making onboarding for new developers and collaboration quite difficult.

The "hybrid" approach that was working for a smaller team at the start of the project would not scale well as the team and customer-base grow.

"I think that in the back of our minds, that was always a problem," Bukczynski said.

Choosing Atlas

"Until Atlas came along, I just don't think there was a tool that could do it."

As time went on and the issues piled, Bukczynski came across Atlas. Having used Terraform extensively to manage AWS infrastructure, the analogy immediately clicked: "When I saw it described as Terraform for your database, it resonated. Just like Terraform gave us control, repeatability, and confidence in infrastructure changes, we needed the same for our schema."

What set Atlas apart was its declarative approach: defining the desired end-state of the database schema in versioned code, then letting Atlas automatically plan and apply the minimal set of changes to reach that state. This model removed the need for hand-crafted migration chains and allowed the team to reason about schema diffs the same way they reasoned about infrastructure plans.

It also integrated smoothly with CI/CD pipelines and gave the team confidence that changes would be applied in a consistent, predictable way, all with full Git history and rollback capability.

Bukczynski began integrating it into their workflow, but due to the complexity of their setup, reached out to the Atlas team for support. "You said, 'You're 90% of the way there,' and committed to solving the other 10%. That was good enough for me."

Outcome

"I don't feel afraid to hit the approve button and pack up and go home for the day"

Adopting Atlas transformed how Darkhorse Emergency manages its database lifecycle:

• Broader Contributor Base: Developers who previously avoided the database can now safely contribute to schema changes. "It's definitely made it possible for others on the team to start contributing to the database where they otherwise would have been afraid to touch it," said Bukczynski.

• Faster, Safer Migrations: With schema changes defined as code and automatically planned, the team now averages more than one migration per day - a cadence that was previously unthinkable in their manual process.

• Confidence in Delivery: Automated CI checks and deterministic planning have enabled near push-button deployment. "I don’t feel afraid to hit the approve button and pack up and go home for the day," Bukczynski shared.

• Local Development Unlocked: Dockerized Postgres environments - initially built to support Atlas - have since evolved into a full local dev stack, making it easier for app developers to spin up isolated, production-like environments.

• Compliance-Ready Process: The structured, auditable workflow helped prepare the team for HIPAA compliance and supports future efforts toward SOC 2.

By replacing fragile scripts with declarative, testable schema management, Darkhorse now ships database changes faster, more safely, and with far less operational anxiety - all while maintaining the integrity of a deeply complex Postgres system built for public safety.

Getting Started

Atlas brings the declarative principles of infrastructure-as-code to databases — much like Terraform, but designed specifically for managing schema changes.

It lets teams define their desired schema state in code, plan migrations automatically, validate changes in CI, and deploy with confidence. For Darkhorse Emergency, it replaced fragile scripts with a reliable, versioned workflow that now runs as part of daily development.

If you're working with relational databases and want a more structured way to manage schema changes:

→ Start with the quickstart

→ Join our Discord

→ And begin managing your schemas as code.