# skeema: Declarative Schema Management for MySQL and MariaDB > Skeema treats a database schema as a directory of CREATE statements under version control, then generates the DDL for you by diffing that directory against a live database, so schema changes travel through pull requests like code changes. It ships linter rules for schema design, hooks into online schema change tools, and runs as a single Go binary. **skeema/skeema** — Declarative pure-SQL schema management for MySQL and MariaDB - Repository: https://github.com/skeema/skeema - Stars: 1,381 · Forks: 105 - Language: Go - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/skeema-skeema ## The Schema Is a Directory of CREATE Statements Skeema is a tool for managing MySQL and MariaDB schema changes in a declarative fashion using SQL CREATE statements, and the first capability in the list is the one that defines the model. You export CREATE statements from your database and track them in an organized repository. Each table, procedure or object is placed in its own file, for easy browsing and reference, and you use standard git commands to see the history on a per-object basis. The per-object file layout is the detail that matters in practice. A single schema file gives you a diff of the whole schema on every change, which is unreadable. One file per table gives you a diff of one table, and a review that a human can actually read, and it means a change to one table cannot be mistaken for a change to the schema. The README also makes a point that is timely. This provides vital context to AI tools, without wasteful intermediate ALTER migrations. A directory of declarative CREATE statements is a description of the desired state, which is the shape an AI tool or a code generator can read, and it is not a pile of imperative migrations whose order matters. So the workflow is: the repository holds what the schema should be, and the tool works out what has to happen to the database to get there. ## Diffing the Live Database Against the Repo The second capability is the one that produces the DDL. Skeema auto-generates DDL by performing diffs between live databases and your schema repo, and the README makes a strong claim about that code path: it is battle-tested from a decade of use, and trusted by some of the biggest names in tech, including GitHub itself. A decade of use is the meaningful part, because a schema differ is the component that has to get every edge case right. A missing index, a changed column type, a renamed table, each of those has to be translated into DDL that does not lose data, and the failure mode is a broken production database rather than a failed test. The README also points at Skeema's internal safety mechanisms, described as correctness guardrails that ensure the generated DDL is absolutely always correct, and the phrasing is deliberately absolute, which tells you the project treats this as the property it is judged on. The other half of the diff is that it is against a live database, not just against a file. That is what makes the multi-environment story work: the same diff runs against dev, staging and prod, and each environment reports what it would change. ## The Linter Is Where the Policy Lives The third capability applies 20 or more configurable linter rules to proactively catch schema design problems and enforce company policies. That word configurable is the important one. A fixed set of rules would be advice, and advice is not what a schema policy needs. A configurable rule set is the mechanism by which a company says things like, this table must have a primary key, this column must not be nullable, this index name is wrong, and the linter turns each of those into a failure rather than a review comment. The linter can be run over all objects in a directory or schema, or over just the modified objects in a diff, and the README presents the second mode as the one that belongs in a pull request, alongside the first mode as the one that belongs on a schedule. That split is standard for linters and it is the reason the tool is usable in both positions. The other half of the story is the exit code behaviour. The README describes it as perfect for CI use, with well-defined exit code behaviors, and the automation documentation covers integrating Skeema into automated workflows. A linter that cannot fail a build is a report rather than a gate, so the exit code contract is what makes this usable in a pipeline. ## Online Schema Change for the Tables You Cannot Lock The fourth capability is about the DDL actually running. Skeema can be configured to use online schema change tools, such as pt-online-schema-change or gh-ost, for performing non-disruptive ALTER TABLE. The reason this exists is that the DDL Skeema generates is the DDL you would write by hand, and on a large table a plain ALTER TABLE locks it. The online schema change tools do the same restructuring in the background, copying rows into a shadow table and swapping it in, so the table stays available. The part worth highlighting is that Skeema's configuration system even allows you to conditionally use OSC depending on table size, environment, schema, and so on. That is the difference between a tool that forces one strategy and one that lets a small lookup table take a fast path while a large events table takes the careful one. The rule can be written in terms of the size of the table, which is exactly the variable that decides whether a lock is acceptable. The README also notes that Skeema manages multiple environments, for example dev, staging and prod, and keeps them in sync with ease, which is the other half of making this safe: the same change is applied consistently everywhere rather than drifting between them. ## Schema Changes as Pull Requests Skeema supports a pull-request-based workflow for schema change submission, review and execution, and the README states the benefit plainly: this permits your team to manage schema changes in exactly the same way as you manage code changes. That is the whole proposition, and it is worth being precise about why it is valuable rather than merely tidy. A schema change is code that runs against production data, and in most teams it is the one kind of change that does not go through review, because the migration script is written by the same person who needs it deployed. Putting CREATE statements in the repository, with a diff, a lint and a review, puts the change in the same place as everything else, and the same machinery applies. The command surface supports the flow. The repository has separate command files for pulling the schema from a database, pushing the generated changes, diffing, linting, adding an environment, formatting and initialising, which correspond to the steps of that workflow. The documentation index mirrors the same structure, with pages for the schema change workflow, for pipelines and automation, for a configuration guide, a command reference and an option reference, plus a recipes page for common tasks and a FAQ. ## Community Edition, Premium Edition and the Split The edition split is the first thing to check before adopting Skeema, because it decides what you can do at all. This repository is the free open source Community edition of the Skeema command-line tool, and the Community edition supports management of tables and routines, which are the procedures and functions. Builds are provided for Linux and macOS. The paid Premium edition adds support for managing views, triggers and events, and it also includes a native Windows build, seed data management, enhanced TLS options for environments requiring client-side certs or CA verification, and many other improvements. So the boundary is: the objects a game or a service rarely changes by hand, such as views and triggers, are Premium, and the objects that change constantly, the tables, are in the free edition. That is a sensible split, and it means a team whose schema is mostly tables can run the whole workflow on the community edition. Two other details from the credits are worth recording. Support for stored procedures and functions was generously sponsored by Psyonix, the creators of Rocket League, and support for partitioned tables by Etsy, which tells you which kinds of schema the features were built for. The tool was created by evanelias at Index Hint LLC, and the source is copyright 2026 Skeema LLC and the Skeema authors under the Apache License, Version 2.0. ## The Go Implementation Behind the CLI The implementation is a single Go program, and the repository layout shows the structure. The top level is flat, with one file per command: cmd_add_env.go, cmd_diff.go, cmd_format.go, cmd_init.go, cmd_lint.go, cmd_pull.go and cmd_push.go, plus the main file skeema.go, the exit handling in exit.go with its test, the logging in log.go, and a set of test files at the root including skeema_test.go, skeema_cmd_test.go and skeema_tls_test.go. There is an internal/ directory, a testdata/ directory for fixtures, a vendor/ directory, and a .goreleaser.yml for building the releases. The go.mod declares Go 1.26.0 and a small dependency set: ```toml module github.com/skeema/skeema go 1.26.0 ``` The dependencies are the MySQL driver at go-sql-driver/mysql, a word wrapper for terminal output, a diff library, logrus for logging, skeema/mybase as the shared internal library, and the sync and term packages. The MySQL driver is the only heavy dependency, which is what you would expect from a tool that talks to one database and one server. The command names map directly onto the workflow described earlier, pull to take the schema out of a database, push to apply the changes, diff to see what would change, lint to check the rules, and init to set a project up. The exit.go file with its own test is a small thing that says something about how the CI exit code contract is treated. ## Conclusion skeema fits a team that has outgrown hand written ALTER migrations and wants schema changes to be reviewed, diffed and linted the same way code is, and it does not fit a project that needs views, triggers or events, because those are Premium edition features, nor a Windows team, since the community edition builds are for Linux and macOS. Before adopting it, decide which edition you need, since the Community edition covers tables and routines only, and note that the linter is where most of the value sits for a team with a schema policy, because 20 or more configurable rules catch design problems before they reach a database. The source is Apache-2.0 licensed, the newest release is v1.14.1 from 2026-07-23, and the last push was on 2026-10-15. ## FAQ ### What does Skeema do? It manages MySQL and MariaDB schema changes in a declarative fashion using SQL CREATE statements. You export CREATE statements from your database into a repository with one file per object, and Skeema generates the DDL by diffing that repository against live databases, so schema changes are managed the same way as code changes. ### What can the free Skeema Community edition manage? Tables and routines, which are the procedures and functions, with builds for Linux and macOS. Support for views, triggers and events, a native Windows build, seed data management and enhanced TLS options are part of the paid Premium edition. ### How does Skeema handle large tables? You can configure it to use online schema change tools, such as pt-online-schema-change or gh-ost, for non-disruptive ALTER TABLE operations, and the configuration can conditionally use them depending on table size, environment or schema. ### What does the Skeema linter do? It applies more than 20 configurable rules to catch schema design problems and enforce company policies, either to all objects in a directory or schema or to just the modified objects in a diff, with well defined exit code behaviour that makes it usable as a CI gate. ### What is the Skeema licence and where are the releases? The Skeema Community Edition source code is copyright 2026 Skeema LLC and the Skeema authors under the Apache License, Version 2.0, with the full text in the LICENSE file. The newest release is v1.14.1 from 2026-07-23, and the last push was on 2026-10-15. ## Sources - [Issues](https://github.com/skeema/skeema/issues) - [License: Apache-2.0](https://github.com/skeema/skeema/blob/main/LICENSE) - [README](https://github.com/skeema/skeema/blob/main/README.md) - [Releases](https://github.com/skeema/skeema/releases) - [skeema/skeema on GitHub](https://github.com/skeema/skeema) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/skeema-skeema