Stop Hand-Writing ALTER TABLE Statements: Manage Database Schemas as Kubernetes Resources
If you're running databases alongside your Kubernetes workloads, you've probably dealt with the awkward split between two worlds: your application config lives in YAML and gets applied with kubectl, while your database schema lives in migration files, ad-hoc SQL, or someone's memory. SchemaHero is a Kubernetes Operator that tries to close that gap by letting you express database table schemas as Kubernetes resources.
What It Does
SchemaHero is a Kubernetes Operator built for declarative schema management across various databases. Instead of writing and tracking migration scripts by hand, you define your table schemas as Kubernetes resources and deploy them to your cluster like anything else.
The operator does the heavy lifting when things change. If you edit a schema and deploy it, SchemaHero calculates the required change—the ALTER TABLE statement—and applies it for you. It's not limited to databases running inside your cluster either. SchemaHero can manage databases deployed to the cluster as well as external ones like RDS or Google CloudSQL. It's written in Go, which you can confirm from the Go Report Card and Godoc badges on the repo.
Why It's Cool
-
Your schema becomes infrastructure. This is the core idea, and it's a good one. If you already treat your Kubernetes manifests as the source of truth for your application, extending that same model to your database tables removes a whole category of drift. No more wondering whether the migration that ran in staging matches what's in production.
-
It handles the diffing for you. The README is explicit that SchemaHero calculates the required change and applies it. That means you're declaring the desired end state rather than scripting the transition. For teams who've been burned by hand-written migrations, that's a meaningful shift in how you think about schema changes.
-
External databases are first-class. Plenty of Kubernetes tooling quietly assumes everything runs in-cluster. SchemaHero doesn't. Supporting RDS and Google CloudSQL out of the box means you can adopt it even if your database isn't containerized—which, let's be honest, describes a lot of production setups.
-
It fits the operator pattern you already know. If you've worked with other Kubernetes Operators, the mental model here is familiar. Schemas are resources, the operator reconciles them, and you interact with the cluster the same way you always do.
How to Try It
The recommended installation path is the kubectl plugin. The full instructions, along with other installation methods, live in the documentation.
- Head to the installing with kubectl docs and follow the setup for the plugin.
- Once installed, work through the tutorial—it walks you through the basics end to end.
- For the broader picture, including how to create tables and manage them, browse the full documentation.
- If you want to see the source or contribute, the repo is at github.com/schemahero/schemahero.
If you get stuck, there's a Replicated Community forum and a #schemahero channel in Kubernetes Slack. The project also maintains a Community page with contribution guidance. And if you end up using it in production, the maintainers ask that you add yourself to the ADOPTERS file.
Final Thoughts
SchemaHero is a focused tool that solves a specific, real problem: keeping database schemas in sync with the declarative workflows you already use for everything else in Kubernetes. It's best suited to teams already comfortable with the operator model who want their schema changes to go through the same review-and-apply pipeline as their application config. If you're running a single database and deploying manually, this might be more machinery than you need. But if you've got multiple environments, external databases, and a growing pile of migration scripts, it's worth a look. The project is open source, the docs are thorough, and the community channels are open if you want to poke around before committing.
Follow @githubprojects for more developer tools and open source projects.