Today we’re excited to announce the 0.9.0 release of SchemaHero. SchemaHero continues to be an OSS project we use internally and believe others will find useful as they move to Kubernetes. This release includes the ability to build custom workflows around schema migration approval (and rejection), a new kubectl plugin to manage SchemaHero, early support for HashiCorp Vault and CockroachDB and more.

Workflows

SchemaHero migrates a database schema by inspecting the current schema of a database and then automatically generating a migration script (DDL) to convert the current schema to the desired version. Since the early days of SchemaHero, this has required a high level of trust in the process because migrations had the ability to drop columns and perform other destructive actions. While we continue to believe that automating this process end-to-end is a noble goal, not everyone is ready to trust a new product with this type of elevated permissions.

Starting with SchemaHero 0.9.0 we’ve added an (optional) approval workflow to the deployment process. This feature is enabled by default on all new and upgraded installations. We’ve separated the “plan” and “apply” phases of schema migration, and designed a method to connect any manual or automatic process into the deployment, before applying migrations generated by SchemaHero. With this feature, a migration is planned, and the generated SQL statements can be reviewed and approved or rejected. The SQL statements are executed only after approval.

Kubectl Plugin

Until now, SchemaHero was only a Kubernetes Operator, meaning that it runs silently in your cluster, managing database schema migrations. We’ve added a kubectl plugin, available today in the krew repository, to help manage database schemas.

While you can still completely automate SchemaHero, this plugin is designed to build native support into managing database schemas into the familiar kubectl utility.

You can get started with SchemaHero now by simplifying installing the kubectl plugin and running kubectl schemahero install.

HashiCorp Vault

HashiCorp Vault is a popular and secure way to manage access into a running database. Instead of static credentials, Vault runs and creates temporary credentials, as needed. With this release of SchemaHero, it’s possible to include a vault configuration in a database manifest, and SchemaHero will interact directly with Vault to create and use database credentials, when needed to plan or apply a migration. Thanks to the hard work by github.com/pauldthomson for this one!

CockroachDB support

We’ve added native support for CockroachDB (v19 and v20) into SchemaHero 0.9.0. There’s a lot more we’d like to add to make SchemaHero the best way to manage CockroachDB schemas, but as of now, we have created the drivers and are validating every release with a CockroachDB cluster.

Operator-less Mode

SchemaHero 0.9.0 introduces a new way to use SchemaHero to manage database schemas if you don’t have Kubernetes or cannot install the full SchemaHero Operator to your cluster. With this mode, you can still run plan and apply phases separately, but there’s no state managed by the in-cluster operator. To support these phases, SchemaHero supports running schemahero plan to get the generated SQL statements and then schemahero apply to apply them.

Shell

A new experimental feature we worked into 0.9.0 is the ability to get a shell into the database engine, using the kubectl plugin. Even if the database engine is not accessible from your workstation, the shell is piped through the SchemaHero manager running in your cluster. This is disabled by default, but can be turned on by setting enableShellCommand to true in the Database custom resource.

What’s Next?

We’d love to hear from you, if you are running SchemaHero or want to run SchemaHero in your environment. What features, compatibility or controls would make it easier to install and run in your environment?