Snowflake's cloud data platform has transformed data warehousing, yet many teams still manage schema changes using manually-composed SQL scripts and verification processes. As data teams grow and pipelines become more complex, these approaches often become more challenging to maintain and much riskier to use.

Schema changes in production environments can quickly lead to unexpected behavior and inconsistent data, and having more contributors increases the risk of human error leading to costly downtime or data integrity issues. These cases are familiar to many data teams because the traditional manual database deployment methods come with implicit risks.

To address these challenges, Snowflake teams have begun adopting tools to automate schema changes, enforce safety checks, and ensure consistent deployments across environments.

In this post, we will compare three popular Snowflake schema management tools – Atlas, schemachange, and SnowDDL – and guide you in building reliable CI/CD pipelines to deploy schema changes with more confidence and control.

AI agents are becoming a core part of daily development. We utilize them to help us write code, fix syntax errors, and perform tasks that speed up routine work. However, when it comes to high-risk operations like database schema changes, we are more hesitant to hand off control to these AI agents.

While you can leverage the AI agent's abilities to generate migrations and make suggestions, you need to ensure the safety of these operations.

Atlas is a database schema management tool that ensures safe and reliable schema changes. Users define their schemas as code, and Atlas performs migrations based on changes to these code definitions. With Atlas, you can configure lint checks, pre-migration validations, and schema testing, making it an ideal counterpart for AI agents.

In this post, we'll show you how to configure popular AI agents to work with Atlas to ensure that schema changes made by the agent are secure.

"I rely on Atlas because I know it works and it gets the job done."

– Hicaro Adriano, Principal Software Engineer, Beck's Hybrids

Company Background​

Founded in 1937, Beck's Hybrids appreciates the farmers who have helped them grow to become the largest family-owned retail seed company and third-largest seed brand in the United States. This position gives Beck's access to the best genetics and trait technologies from suppliers worldwide. Beck's strives to provide all customers with the tools, support, and resources they need to succeed.

The Obstacle: Unreliable Migrations​

The Beck's Hybrids IT department began with a few engineers managing mainframes. Over the years, the development team has grown in an effort to provide customers and internal users with various applications that help power all aspects of the business. These systems include "FARMServer®", a precision farming platform that helps farmers make decisions based on optimal planting windows and growth stage modeling.

FARMServer is a complex, Microsoft SQL Server-based application that has grown to include a wide range of features and functionalities. Its codebase heavily utilizes stored procedures, views, and custom types to handle the intricate logic required for precision farming.

Beck's has traditionally developed its technologies in-house, and that includes their schema management system for these applications. Their system was a semi-automatic process that required manually written migrations, which can be quite fragile.

Their process required developers to manually track which revisions had been applied, carefully compare that to the current state in production, and then apply the remaining changes one-by-one - "hoping they wouldn’t fail." With no batch transactions or safety mechanisms in place, even a small mistake often left production in an inconsistent state.

Hey everyone!

We're excited to announce the release of Atlas v0.36 with a comprehensive set of new features and improvements that further strengthen Atlas as your go-to database schema management tool:

• Snowflake Driver Beta - Atlas now supports Snowflake databases in beta, expanding our data warehouse schema management capabilities.
• PostgreSQL Partitions - Declarative management of PostgreSQL partitions has long been a top community request, and we are excited to say it's now available!
• Azure DevOps Integration - Seamless CI/CD integration with Azure DevOps pipelines for database schema management.
• Google Spanner Beta - Beta support for Google Cloud Spanner, bringing Atlas to Google's horizontally scalable and globally distributed database.
• Datadog SIEM Support - Enhanced security monitoring with Datadog integration for audit logs and schema monitoring.
• ORM Schema Linting - Advanced schema validation and policy enforcement for all supported ORM integrations.
• Explain Pipelines Errors - New AI-powered error explanations to help you quickly understand and resolve deployment errors with Atlas Pipelines.

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:

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.

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.

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

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.

• Ad-hoc Approval Policies for Terraform and GitHub Actions - You can now control when Atlas will require explicit approval during declarative migrations with ad-hoc approval policies.
• Terraform Doc Portal – There is now a portal in our docs dedicated to helping you get started integrating Atlas with your Terraform setup.

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.