Skip to main content

Schema Rules: Enforcing Database Policy with Atlas

· 4 min read
Chinh Nguyen
Software Engineer

Atlas manages and migrates database schemas by following modern DevOps principles. This includes allowing teams to define and enforce custom rules for their database schemas to ensure consistency, compliance, and best practices throughout the development lifecycle.

Here's a breakdown of what Atlas Schema Rules are, why they are beneficial, and how to implement them:

Tame Complex PostgreSQL Schemas with Atlas, a Terraform for Databases

· 7 min read
Rotem Tamir
Building Atlas

As applications grow, their underlying database schemas inevitably grow more complex. What often starts as an afterthought handled by a single developer quickly turns into a critical, high-risk responsibility that demands precision and discipline.

Tools like Flyway and Liquibase automate the application of schema changes, but they stop short of addressing the real pain points: planning and validating those changes before they hit production. These steps remain largely manual, error-prone, and disliked by most developers.

Atlas is designed to fill this gap by automating the entire lifecycle of schema changes. Inspired by Terraform, Atlas provides a declarative approach to database schema management, enabling teams to define their schemas as code and automate the planning, validation, and application of changes.

Why Terraform for Databases?

Infrastructure teams have standardized on tools like Terraform to manage cloud resources declaratively. Databases, despite being critical infrastructure, often remain outside this workflow. Schema changes are still handled manually or with ad-hoc migration scripts, leading to drift, unpredictability, and production risks.

Atlas v0.35: Oracle, Bootstrap Projects, and more

· 9 min read
Rotem Tamir
Building Atlas

Hey everyone!

It's been just over a week since our last release, and we are back with another batch of exciting features and improvements. Here's what's in store for you in Atlas v0.35:

  • Bootstrap Projects - You can now bootstrap SQL projects with one command, making it easier to get started with Atlas. Using the new split and write template functions, you can now create a code representation of your database schema in SQL or HCL format to turn your database into code in no time.
  • Atlas for Oracle in Beta - We are excited to announce that Atlas is now in beta for Oracle databases.

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

· 7 min read
Noa Rogoszinski
Noa Rogoszinski
DevRel Engineer

"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.

Atlas v0.34: Ad-hoc Approval Policies and Terraform Docs

· 3 min read
Rotem Tamir
Building Atlas

Hey everyone!

It's been just over two weeks since our last release, and we are back with another batch of exciting features and improvements. Here's what's in store for you in Atlas v0.34.

Building scalable multi-tenant applications in Go

· 20 min read
Rotem Tamir
Building Atlas

Prepared for and presented at GopherCon Israel 2025.

Introduction

In this post, we will explore different strategies for building scalable multi-tenant applications in Go based on our experience building the backend for Atlas Cloud, which is part of our commercial offering.

But first, let's clarify what we mean by multi-tenant applications.

Multi-tenancy is a property of a system where a single instance serves multiple customers (tenants).

As a commercial enterprise, your goal is, of course, to have lots of customers! But while you want to serve many customers, they expect a smooth and seamless experience, as if they were the only ones using your service.

Two important promises you implicitly make to your customers are:

  1. Data Isolation: Each tenant's data is isolated and secure, ensuring that one tenant cannot access another's data.
  2. Performance: The application should perform well regardless of the number of tenants, ensuring that one tenant's usage does not degrade the experience for others.

Let's explore some ways in which we might fulfill these promises.

Atlas v0.33: Introducing Atlas Copilot and more

· 10 min read
Rotem Tamir
Building Atlas

Hey everyone!

It's been a couple of months since our last release, but for good reason. Today, I am super excited to tell you about everything we have been up to. Here's what's in store for you in this release, v0.33:

  • Atlas Copilot: A new coding assistant that helps you better manage your Atlas projects by leveraging an agentic, LLM-based approach.
  • Support for --include: Atlas Pro users may now use the --include flag to specify which database objects to query during inspection.
  • migrate/diff in GitHub Actions, GitLab CI, and CircleCI - Atlas now supports the migrate diff command in GitHub Actions, GitLab CI, and CircleCI. This allows teams to build CI/CD pipelines that automatically generate migration files based on the current state of the database and the desired state of the schema.
  • Check-level Lint Policies: Atlas comes pre-packaged with many built in analyzers that can be used to verify the safety of changes to your database. Using Check-level Lint Policies, you can now configure your CI/CD's pipelines sensitivity to these analyzers.
  • Support for sensitive annotations in migration files: Migration files can sometimes include sensitive or PII values, either passed in as input variables (using template-directories) or embedded directly in SQL statements. To prevent these values from being logged, Atlas provides a directive for marking files or specific statements as sensitive. This directive can be set at either the file or statement level.
  • Atlas Dashboard UI Revamp: We recently revamped the Atlas dashboard UI. The new design is cleaner and more modern, making it easier to navigate and find the information you need. Congrats to the team for their hard work on this!
  • Beta / Feedback Programs: We are launching beta/feedback programs for (signup link below):
    • Oracle
    • Google Spanner
    • Snowflake
    • Performance Optimization

From Manual to Automated Database Schema Migrations

· 7 min read
Noa Rogoszinski
Noa Rogoszinski
DevRel Engineer

Software teams commonly embrace DevOps for delivery, creating automated CI/CD pipelines that allow for rapid and reliable software delivery. Suprisingly, some of these same teams still manage their database schema manually, causing an interesting contrast.

Picture this: a team spent countless hours ensuring that every change to their application code is:

  • Version controlled
  • Automatically tested, built, and stored in an Artifact Repository
  • Automatically deployed
  • Easily rolled back

Yet when it comes to making changes to their database schema, the process looks very different: a developer writes a SQL migration script, connects to the production database with privileged access, runs the script manually, and (if successful) continues with deployment. The entire process is in the hands of the developer.

Projects frequently begin with manual database schema management because it's the easiest option, particularly when databases are small, changes are infrequent, and there are no users. However, as applications evolve and schema migrations grow more complex, this practice becomes a looming risk.

Let's explore the pitfalls of manual migrations, the benefits of automated migrations, and getting started with Atlas to automate your database schema management.

Handling Migration Errors: How Atlas Improves on golang-migrate

· 11 min read
Noa Rogoszinski
Noa Rogoszinski
DevRel Engineer

Database migrations are fundamental to modern software development, allowing teams to evolve their database schema in a controlled and versioned manner. As applications grow and requirements change, the ability to reliably alter your database is crucial for maintaining data integrity and application stability.

Atlas was originally created to support Ent, a popular Go ORM. From the start, Ent shipped with a simple "auto-migration" feature that could set up the database schema based on the Ent schema. However, as the project grew popular, it became clear that a more robust versioned migration system was needed.

Ent's authors had hoped to add functionality based on the existing "auto-migration" engine to generate migration files, and use an off-the-shelf migration tool to apply them. The most promising candidate was golang-migrate, a widely adopted migration tool in the Go community renowned for its simplicity and wide database support. But like many tools that start simple and grow popular, we realized that golang-migrate, too, has its limitations, and they led us to expand on its abilities.

In this article, we’ll explore some common challenges teams face with traditional migration tools like golang-migrate, and how Atlas takes a different approach to improve the developer experience.

The Missing Chapter in the Platform Engineering Playbook

· 12 min read
Rotem Tamir
Building Atlas

Prepared for SREDay London 2025

Introduction

Platform engineering is rapidly emerging as a discipline aimed at reducing cognitive load for developers, enabling self-service infrastructure, and establishing best practices for building and operating software at scale. While much of the conversation focuses on CI/CD, Kubernetes, and internal developer platforms, one crucial aspect often remains overlooked: database schema management.

Despite being at the heart of nearly every application, schema changes are still a major source of friction, outages, and bottlenecks. In this post, we'll explore why database schema management deserves a dedicated chapter in the platform engineering playbook and how organizations can integrate it into their platform strategies.

The prompt that nuked the database

Let me tell you a not-so-fictional story about a developer named Alice. Alice is a backend engineer at a fast-growing startup. One day, her manager asked her to make a small change to the database. The data engineering team was complaining that they were seeing duplicate emails in the user table, and they suspected that the email column did not have a unique constraint.