Ridgepole

DB Schema

Declarative database schema management with a single Schemafile

Manages: Database Schema (Rails/ActiveRecord)
Language: Ruby
Package: ridgepole
CLI: ridgepole
Config file: Schemafile

Schemafile

create_table "articles", force: :cascade do |t|
  t.string   "title"
  t.text     "text"
  t.text     "author"
  t.datetime "created_at"
  t.datetime "updated_at"
end

create_table "comments", force: :cascade do |t|
  t.string   "commenter"
  t.text     "body"
  t.integer  "article_id"
  t.datetime "created_at"
  t.datetime "updated_at"
end

add_foreign_key "comments", "articles"

In short

Ridgepole is a Ruby tool that manages your database schema as code. You describe every table, column, and index in one file called a Schemafile. Ridgepole compares that file to MySQL or PostgreSQL and runs only the changes needed, idempotently. It replaces piles of Rails migration files with one readable schema.

What is Ridgepole?

Ridgepole is a declarative database schema tool built on ActiveRecord. Instead of piling up migration files, you write the schema you want in one file. It holds every table, column, index, and foreign key. Ridgepole compares that file to the live database and runs only the SQL needed to match them. This is codenization applied to the database.

The problem it solves is migration sprawl. After a few years, a Rails app has hundreds of migration files. Many no longer run cleanly from scratch. The generated schema file becomes an output nobody trusts as the real definition. Ridgepole flips this around:

The Schemafile is the single source of truth, readable in one place.
A schema change is an ordinary diff in a pull request.
Applying the same file twice is a safe no-op.

Ridgepole is the flagship of this site and the one clearly active project here. It came out of Cookpad and runs in production at many Ruby shops. It works with or without Rails. Teams often pair it with Gratan for MySQL grants and Posgra for PostgreSQL roles, so schema and permissions both live in Git.

Key facts

Manages your database schema: tables, columns, indexes, and foreign keys.
The whole schema lives in one Rails-style DSL file, the Schemafile.
It is declarative: you describe the end state and Ridgepole computes the DDL.
A dry-run prints the exact SQL before it touches the database.
Works with MySQL, PostgreSQL, and Trilogy, with or without Rails.
Unlike the AWS tools here, Ridgepole is actively maintained.

Illustration: Database Schema (Rails/ActiveRecord) managed as code with Ridgepole

Getting started

Install and run Ridgepole

Install

Install the ridgepole gem (Ruby required).

$ gem install ridgepole

Export current state

Pull the live DB Schema configuration into a Schemafile.

$ ridgepole -c config.yml --export -o Schemafile

Dry-run, then apply

Preview the diff, then apply the change for real.

$ ridgepole -c config.yml --apply --dry-run

Ridgepole follows the same export, review, apply workflow as the AWS codenize tools, pointed at your database. Adopt it on an existing system in export mode (the --export flag), which reads the live schema into a Schemafile. Commit that file; it replaces the pile of migrations as the single source of truth.

A schema change is then an edit to the Schemafile in a branch: add a column, an index, a foreign key. Run the apply with --dry-run to see the exact DDL and include it in the pull request, so reviewers can reason about locks and long ALTERs. On merge, CI applies the file to each environment. The apply is idempotent, so re-running changes nothing, and the diff mode between two configs doubles as drift detection across environments.

Pro tip

Always read the dry-run DDL before applying. It reveals an ALTER TABLE that would rewrite a huge table, so you can schedule it in a maintenance window instead of finding the lock in production.

Capabilities

What Ridgepole can do

Declarative Schemafile instead of migrations

The full schema lives in one Rails-DSL file, splittable with require. Ridgepole works out the ALTER and CREATE statements itself, so there are no migration files to write, order, or replay.

True diff engine

Beyond applying files, the diff mode compares any two schema sources: two files, two databases, or a file and a database. It is easy to verify that staging and production actually match.

Dry-run shows the exact DDL

The dry-run prints the SQL that would run. Reviewers can judge locking and data-safety before a change reaches the database.

Safe renames with renamed_from

Columns and tables can declare renamed_from. A rename then runs as a real RENAME instead of a destructive drop-and-add, so data is preserved.

Real production database features

The DSL covers foreign keys, CHECK constraints, expression indexes, collation and charset options, and MySQL generated columns. It is built for real schemas, not toy ones.

MySQL, PostgreSQL, and Trilogy support

Ridgepole works with MySQL including 8.0, PostgreSQL, and the Trilogy adapter, tracking modern Rails and ActiveRecord versions. SQLite is not supported.

Ridgepole Schemafile vs Rails migrations

How declarative schema management compares to writing migration files.

	Ridgepole Schemafile	Rails migrations
Style	Declarative: describe the end state	Imperative: describe each step
Files	One `Schemafile`	Many timestamped files
Current schema	Readable at a glance	The sum of every past migration
Run it twice	Safe no-op (idempotent)	Tracked by version number
Rename a column	`renamed_from` keeps the data	A hand-written rename step
Data changes	Written separately	Can live inside a migration

In practice

When teams reach for Ridgepole

Replace migration sprawl in mature Rails apps

Long-lived Rails codebases collect hundreds of migrations that are risky to replay and hard to read. Exporting once to a Schemafile gives one readable definition, and every later change is a plain diff.

One schema, many databases

Services that shard by tenant or run per-environment databases need the same schema everywhere. Applying the same Schemafile to each guarantees convergence, and the diff mode catches any shard that quietly drifted.

Schema management outside Rails

Ridgepole needs only a database config and a Schemafile. Teams use it to manage MySQL and PostgreSQL schemas for Go or Python services, still getting ActiveRecord's mature DDL and a reviewable schema in Git.

Review DDL before it locks production

The dry-run prints the literal SQL. A reviewer can spot an ALTER TABLE that would rewrite a 500-million-row table and schedule it, rather than discovering the lock after deploy.

FAQ

Ridgepole questions, answered

How is Ridgepole different from Rails migrations?

Migrations are imperative and historical: each file is a step, and the schema is whatever the steps add up to. Ridgepole is declarative: the Schemafile describes the end state and the tool computes the steps. That keeps the current schema readable and applies idempotently, but you manage changes through diffs rather than timestamped files. Data migrations are still written separately.

Is Ridgepole production-ready and maintained?

Yes. Ridgepole came out of Cookpad, where it has managed production schemas for years, and it stays actively maintained with regular releases that track current Rails and ActiveRecord. Of the tools in the codenize family, it is the clear case of an actively supported project.

Can Ridgepole destroy data?

It can, which is why the safeguards exist. Dropping tables requires opting in explicitly, renames should use renamed_from so they run as RENAME instead of drop-and-add, and the dry-run shows the exact DDL first. Standard practice is to gate every apply behind a reviewed dry-run.

Which databases does it support?

MySQL including 8.0, PostgreSQL, and the Trilogy MySQL adapter. SQLite is not supported. Because it rides on ActiveRecord, the supported column types and options track whatever your ActiveRecord version supports.

Do I have to use Rails to use Ridgepole?

No. Ridgepole is a standalone CLI that needs only a database config, such as a config.yml or a connection URL, and a Schemafile. Many teams use it to manage schemas for services in other languages, keeping the schema in version control next to the service.