database governance as code with atlas

Define roles, permissions, and schema policies as code. Enforce them in CI/CD, audit every change, and detect drift across environments.

Define roles, permissions, and schema policies as code. Enforce them in CI/CD, audit every change, and detect drift across environments.

Schedule a Demo Start Free See the Solution

What it covers

Governance, control by control

Database governance is the set of controls that decide who can change a database, which changes are allowed, and how each change is reviewed and recorded. Atlas enforces all six from one declarative source.

ControlHow Atlas enforces itReference

Access management

Roles, users, permissions, and row-level security policies are declared as code and applied like any other schema change.

Security as Code

Schema policy

Custom rules assert conventions and compliance requirements over every object in the schema: naming, required columns, RLS, view and function security.

Custom Schema Policy

Migration safety

Built-in analyzers flag destructive changes, table locks, and backward-incompatible statements while the change is still a pull request.

Migration Analyzers

Change review

Every schema and permission change lands as a reviewed pull request, with the plan and the lint report posted back as a PR comment.

Environment promotion

Per-environment policy decides which changes are allowed, what has to pass first, and which environment must already be current.

Project Configuration

Drift and auditing

Continuous monitoring compares live databases against their declared state and keeps a history of who changed what, when, and from which deployment.

Drift Detection

See the setup path

The Problem

Database governance is still manual

Access control, schema policies, migration safety, environment promotion. The requirements are clear, but in practice each is managed through a different tool, team, ad-hoc process, or non-deterministic AI suggestion with no guaranteed enforcement.

Access control is ad-hocRoles, users, and grants are managed through one-off commands with no version control or review process.

Schema changes bypass policyDestructive operations, table-locking migrations, and backward-incompatible changes reach production unchecked.

No promotion gatesChanges skip lower environments entirely. Production deploys are not gated on staging state.

Drift goes undetectedManual changes create gaps between the declared state and live databases that widen until an incident occurs.

change-log

5 UNREVIEWED

03:41

GRANT ALL ON *.* deploy_botby deploy_bot

no approval

03:42

DROP COLUMN orders.legacy_idby deploy_bot

destructive

03:43

CREATE INDEX idx_users_emailby admin

locks table

03:58

ALTER ROLE superuserby unknown

no review

04:01

APPLY MIGRATION prod (skipped staging)by admin

env skip

No policy engine configured

2

2

1

How Atlas solves this

Security as Code

Define database access as code

Atlas lets you define database roles, users, and permissions as code. Reviewed in PRs, deployed through CI/CD, tracked in Git, and enforced with policies. The same workflows used for schema management now apply to access control.

Declarative, not imperativeDefine the desired state. Atlas diffs live permissions and applies only what changed.

Reviewed and versionedEvery permission change goes through a pull request. Full audit trail in Git.

Credentials stay out of codePasswords are injected from your secret manager at runtime, never stored in files.

roles.hcl

permission.hcl

users.hcl

1role "app_readonly" {
2  comment = "Read-only application access"
3}
4
5role "app_writer" {
6  member_of = [role.app_readonly]
7}
8
9role "app_admin" {
10  create_db   = true
11  create_role = true
12  member_of   = [role.app_writer]
13}

terminal

~/atlas/prod

Policies as Code

Enforce standards automatically

Define rules for schemas, migrations, and permissions in code. Atlas enforces them in CI. No unsafe changes reach production without explicit approval.

Enforce security policiesDisallow superuser roles, block grantable permissions, and require invoker security on views.

Prevent unsafe schema changesBlock destructive ops, backward-incompatible changes, and unsafe migrations in CI.

Govern access with custom rulesRequire row-level security on all tables, enforce restrictive policies, and audit function security.

security.hcl

atlas.hcl

rules.hcl

1rule "schema" "no-superuser" {
2  role {
3    assert {
4      predicate = predicate.role.not_superuser
5      message   = "superuser roles are prohibited"
6    }
7  }
8}
9
10rule "schema" "no-grantable" {
11  permission {
12    assert {
13      predicate = predicate.perm.not_grantable
14      message   = "WITH GRANT not allowed"
15    }
16  }
17}
18
19rule "schema" "view-invoker" {
20  view {
21    assert {
22      predicate = predicate.view.security_invoker
23      message   = "must use INVOKER security"
24    }
25  }
26}

terminal

~/atlas/app

Environment Governance

Controlled promotion across environments

Every migration goes through a reviewed, gated lifecycle before it reaches production. No change skips staging, no artifact is modified after approval.

Validate in CIEvery pull request is checked against your governance policies. Changes that violate security rules, access controls, or schema policies are blocked before they reach the main branch.

Push to registryApproved migrations are tagged with the commit SHA and pushed as immutable, signed artifacts.

Gate on stagingProduction deploys are blocked unless the target version has been applied to staging first.

Deploy from registryProduction applies migrations from the registry, never from local files. Full audit trail in Atlas Cloud.

pull request

feat/add-orders-table#142 opened by @dev

checks passed

Detect schema changes

3s

Run migration lint

8s

Validate schema policies

4s

Simulate on dev database

12s

Check drift and conflicts

2s

5 of 5 checks passed

ready to merge

migration lifecycle

PR ValidationLint, policy, conflict checks

Registry PushImmutable versioned artifact

Staging GateStaging must pass first

Production DeployFrom registry, fully audited

deploying

Continuous Monitoring

Detect drift, notify, remediate

Even with policies in place, databases drift from their declared state. Atlas continuously monitors your databases, detects deviations, and notifies your team with single-command remediation.

Continuous monitoringAtlas compares the live database state against your declared schema and policies on every iteration.

Instant notificationsGet Slack alerts the moment drift is detected, with full context on what changed and why.

One-command remediationAtlas calculates the fix and lets you apply it directly, no manual SQL needed.

Acme CorpA

#schema-monitor

1

#

#

#

#

#

#schema-monitor

Atlas Bot2:45 PM

⚠️ Drift detected on table users

Production database schema differs from main branch.

roleRole app_readonly missing GRANT on table orders

userUser deploy_bot has unexpected SUPERUSER privilege

schemaTable audit_log: column added outside migration

Getting started

From a live database to enforced policy

Three steps, no schema rewrite. Atlas reads the databases you already have, and the policy you declare starts gating changes on the next pull request.

01

Point Atlas at your databases

One env block per real environment, plus the rule files that environment is held to. Planning and linting run against an ephemeral dev database, never against your targets.

atlas.hcl

env "prod" { url = env("DATABASE_URL") dev = "docker://postgres/16/dev" lint { rule "hcl" "governance" { src = ["policy.rule.hcl"] } } }

02

Write the policy

Rules assert conditions over schema objects. This one requires row-level security on every table; the same shape covers naming conventions, required columns, and role and permission rules.

policy.rule.hcl

rule "schema" "require-rls" { description = "all tables must enable RLS" table { assert { predicate = predicate.table.has_rls message = "row-level security required" } } }

03

Enforce it, then gate on it

atlas schema lint reports every violation in the schema, so you know where you stand before turning anything on. In CI, atlas migrate lint reports only what the change introduces, so the gate blocks new violations without failing on the backlog.

terminal

$ atlas schema lint --env prod require-rls ✗ table "employees": row-level security required ✓ table "orders": ok $ atlas migrate lint --env prod --latest 1 No violations introduced

Schema Policy Documentation

Vercel

Nvidia

Meta

Trusted by leading companies

Databricks

Intel

Procter & Gamble

Database governance without the overhead

Schedule a Demo Start Free Read the Guide