skeema VS migrate

Personally I've always called this style "declarative schema management" since the input declares the desired state, and the tool figures out how to transition the database to that state.

sqldef is really cool for supporting many database dialects. I'm the author of Skeema [1] which includes a lot of functionality that sqldef lacks, but at the cost of being 100% MySQL/MariaDB-specific. Some other DB-specific options in this space include Stripe's pg-schema-diff [2], results [3], sbt-tester's migrator [4], among many others over the years.

The more comprehensive solutions from ByteBase, Atlas, Liquibase, etc tend to support multiple databases and multiple paradigms.

And then over in Typescript ORM world, the migrators in Prisma and Drizzle support a "db push" declarative concept. (fwiw, I originated that paradigm; Prisma directly copied several aspects of `skeema push`, and then Drizzle copied Prisma. But ironically, if I ever complete my early-stage next-gen tool, it uses a different deployment paradigm.)

[1] https://github.com/skeema/skeema/

[2] https://github.com/stripe/pg-schema-diff

[3] https://github.com/djrobstep/results

[4] https://david.rothlis.net/declarative-schema-migration-for-s...

Yeah unfortunately I think that it's not really possible to hit the speed of a TEMPLATE copy with MariaDB. @EvanElias (maintainer of https://github.com/skeema/skeema about this) was looking into it at one point, might consider reaching out to him — he's the foremost mysql expert that I know.

The article isn't claiming to have invented declarative schema management though. They're just saying it is now available as a feature in Supabase. (Personally I think that's great!)

Regarding prior art: Django migrations are indeed declarative, and were very early in this space. But they're tied to Python model definitions in the ORM, which is a bit more of a special-case than the native SQL CREATE based approach described here.

As for Prisma Migrate, they directly copied several innovations from my tool Skeema [1] which has been available since 2016, so they can be equally accused of "reinventing" things :)

Not that I invented pure-SQL declarative schema management either, by any stretch. I was largely inspired by the workflow at Facebook, who adopted declarative table management company-wide back in ~2012 or so.

[1] https://github.com/skeema/skeema

Yes, this is a possible business model for developer tools. My declarative schema management product Skeema is primarily a CLI tool, available in both FOSS [1] and paid editions, with the latter adding extra functionality and optional premium support [2].

In my space, some larger competitors are more focused on SaaS/cloud offerings. But that can be a mixed bag for security-sensitive customers who prefer to self-host, as well as for folks who want to integrate a tool into an automation/CI/CD pipeline. CLI tools are more compelling in those situations.

[1] https://github.com/skeema/skeema/

[2] https://www.skeema.io/download/

If a tool blindly drops columns, that's just a bad tool! It doesn't mean the concept is flawed.

Thousands of companies successfully use declarative schema management. Google and Facebook are two examples at a large scale, but it's equally beneficial at smaller scales too. As long as the workflow has sufficient guardrails, it's safe and it speeds up development time.

Some companies use it to auto-generate migrations (which are then reviewed/edited), while others use a fully declarative flow (no "migrations", but automated guardrails and human review).

I'm the author of Skeema (https://github.com/skeema/skeema) which has provided declarative flow for MySQL and MariaDB since 2016. Hundreds of companies use it, including GitHub, SendGrid, Cash App, Wix, Etsy, and many others you have likely heard of. Safety is the primary consideration throughout all of Skeema's design: https://www.skeema.io/docs/features/safety/

Meanwhile a few declarative solutions that support Postgres include sqldef, Migra, Tusker (which builds on Migra), and Atlas.

I’d argue the obvious answer is address the lack of great answers for declarative schema migration in PostgreSQL. There is Skeema https://github.com/skeema/skeema but it doesn’t support Postgres and Prisma iirc forces you into an ORM, atlas looks perfect but has a nonstandard license.

Ahh I see now, you've founded https://github.com/skeema/skeema which is great!

Keep it up!

Using tmpfs for MySQL/MariaDB's data directory helps tremendously. If you're using Docker natively on Linux, use `docker run --tmpfs /var/lib/mysql ...` and that'll do the trick. Only downside is each container restart is slightly slower due to having to re-init the database instance from scratch.

Tuning the database server settings can help a lot too. You can add overrides to the very end of your `docker run` command-line, so that they get sent as command-line args to the database server. For example, use --skip-performance-schema to avoid the overhead of performance_schema if you don't need it in your test/CI environment.

For MySQL 8 in particular, I've found a few additional options help quite a lot: --skip-innodb-adaptive-hash-index --innodb-log-writer-threads=off --skip-log-bin

A lot of other options may be workload-specific. My product Skeema [1] can optionally use ephemeral containerized databases [2] for testing DDL and linting database objects, so the workload is very DDL-heavy, which means the settings can be tuned pretty differently than a typical DML-based workload.

[1] https://github.com/skeema/skeema/

[2] https://www.skeema.io/docs/options/#workspace

Atlas hasn’t made it on my radar until now — surprising considering how many stars it has. Based on the description, it looks like it can do something similar to skeema except it isn’t limited to one flavor of sql like skeema. I’m looking forward to trying it out in my next postgres project.

VARCHAR(N) can store N characters. So with utf8mb3, that's a max of 3N bytes worst-case. But with utf8mb4, it's now 4N bytes, which (with a high N) may exceed internal limits such as maximum length of an index key.

IIRC, there were additional problems in older versions of MySQL, situations where sort buffers were sized to a fixed length equal to the value's worst-case size or something like that. So sorting a large number of utf8mb4 values would use a lot more memory than utf8mb3 values (again, iirc, I might be wrong on this).

So the safer and more backwards-compatible approach was to introduce utf8mb4 as a new separate charset, and allow users to choose. MySQL 8 is now transitioning towards deprecating utf8mb3, and will finally make the utf8 alias point to utf8mb4 sometime in the near future.

That said, there are still a bunch of unpleasant uses of utf8mb3 internally in things like information_schema. I develop schema management tooling and recently lost a week to some of the more obscure ones in https://github.com/skeema/skeema/commit/bf38edb :)

# ============================ # Stage 1: Builder (Shared build environment) # ============================ FROM golang:1.25.5-alpine3.21 AS builder RUN apk add --no-cache git ca-certificates curl WORKDIR /build # Copy dependencies first (cache optimization) COPY go.mod go.sum ./ RUN go mod download && go mod verify COPY . . # Static linking build ARG COMMIT=unknown ARG BUILD_TIME=unknown RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build \ -tags timetzdata \ -ldflags="-w -s -X ...app.commit=${COMMIT} -X ...app.buildTime=${BUILD_TIME}" \ -trimpath \ -o myapp \ ./cmd/myapp # Download the migrate tool ARG MIGRATE_VERSION=v4.17.1 RUN curl -L https://github.com/golang-migrate/migrate/releases/download/${MIGRATE_VERSION}/migrate.linux-amd64.tar.gz | tar xvz && \ mv migrate /usr/local/bin/migrate && \ chmod +x /usr/local/bin/migrate

Since migrations are so handy at creating a healthy way to deal with database changes, a great variety of tools exist to manage them in numerous frameworks such as Alembic for Python, migrate for Go, etc.

I used golang-migrate for database migration with Spanner, so here's a note.

//download it curl -L https://github.com/golang-migrate/migrate/releases/download/v4.17.0/migrate.linux-amd64.tar.gz | tar xvz //copy it to go path bin cp -r migrate $GOPATH/bin/migrate //if migrate command does not work //add the folliwng lines to ~./bashrc export GOPATH=$HOME/go export PATH=$PATH:$GOPATH/bin

In this boilerplate, we use golang-migrate/migrate, a production-grade migration tool that integrates well with both automation scripts and CI/CD pipelines. It helps ensure that every environment runs the same schema version — no matter where or when migrations are applied.

The great thing is that dbmate provided a matrix with other migration tools, and there I found migrate.

curl -L https://github.com/golang-migrate/migrate/releases/download/v4.17.1/migrate.linux-amd64.tar.gz | tar xvz sudo mv migrate /usr/local/bin/

Migrate is another popular choice for Go developers. It’s a CLI-first tool that supports a wide range of databases (PostgreSQL, MySQL, SQLite, etc.) and focuses on simplicity and portability. Unlike Goose, Migrate is language-agnostic, so it’s great for teams using multiple languages alongside Go.

For advanced tips, check the golang-migrate docs.