I have a pretty simple rule for database migrations: the tool lets me write SQL, check status, apply the next change, and roll back when I need to. I don’t want much more standing in the way.
\nThat’s why I like both Geni and Goose.
\nNeither one is trying to be a full application framework. They don’t require the rest of the app to be written in the same language as the migration tool. They’re small enough to understand, script, and run from CI, but they have enough features that they don’t feel like a pile of shell scripts once a project grows real production databases.
\nThe catch is that they’re good at slightly different jobs. I’ve ended up using both in the same migration repo: Goose for PostgreSQL, MySQL, and MariaDB, Geni for LibSQL/Turso. That split has worked well enough that I’d reach for the same shape again, even on projects that aren’t written in Go or Rust.
\nUse Goose when you want a mature, widely used SQL migration tool for the traditional server databases: PostgreSQL, MySQL, MariaDB, and local SQLite. Broad database matrix, familiar single-file format, status and rollback commands, environment-variable substitution, Go migrations when you need them, and a very plain CLI.
\nUse Geni when LibSQL or Turso is part of the system. It’s a standalone tool with first-class LibSQL/Turso support, a simple paired-file model, status/up/down/new commands, and optional schema snapshots. It was built for the space where “SQLite-like, but remote and edge-hosted” starts to expose the rough edges of tools designed around local SQLite files.
\nReach for something heavier when migrations stop being ordered SQL files and turn into a schema-management problem. More on that at the end.
\nThe best thing about Geni and Goose is that the migration stays close to the database.
\nThere’s no ceremony around a model layer. You write SQL. You put it in version control. You run a CLI. The database gets a tracking table. A teammate can review the migration in a pull request without learning your ORM. A deploy script can ask for status before it applies anything. For a lot of small and medium projects, that’s exactly the right amount of machinery.
\nIt also makes both tools language-independent in practice. Goose is written in Go, Geni in Rust, but a TypeScript, Python, Ruby, or PHP app can use either one just fine. The migration tool runs at the edge of the application. It talks to the database and the filesystem. It doesn’t need to be imported by the app.
\nThat separation is underrated. A migration directory can outlive a framework rewrite. It can be shared by several services, live in an infrastructure repo, and get run by CI, a deploy script, or a human with a terminal.
\nGoose is the boring choice, in the best sense. Its migration format is easy to read:
\n-- +goose Up\n-- +goose StatementBegin\nCREATE TABLE users (\n id BIGSERIAL PRIMARY KEY,\n email TEXT NOT NULL UNIQUE\n);\n-- +goose StatementEnd\n\n-- +goose Down\n-- +goose StatementBegin\nDROP TABLE users;\n-- +goose StatementEnd\nThe forward and rollback changes live in one file, and a review comment can talk about both in one place.
\nGoose is also strong when a repo has several conventional engines. It documents support for PostgreSQL, MySQL, MariaDB, SQLite, and more, and the command shape stays mostly the same across them:
\ngoose -dir migrations/postgres/app/schema postgres "$POSTGRES_APP_DSN" up\ngoose -dir migrations/mysql/app/schema mysql "$MYSQL_APP_DSN" up\nFor Go services there’s another useful escape hatch: Go migrations. Most schema changes should stay in SQL, but occasionally one needs batching, custom validation, or a data rewrite that’s clearer in code. Goose supports that without forcing every migration to become code.
\nI reach for Goose first on Postgres/MySQL/MariaDB, on teams that already know SQL migrations, and in deploy scripts that just want status, up, down, and version.
Geni has a similar direct feel, but its file model is different:
\nmigrations/\n 1782054288_create_users_table.up.sql\n 1782054288_create_users_table.down.sql\nForward migration in one file, rollback in another, both plain SQL. Geni can create the pair for you:
\ngeni new create_users_table\ngeni status\ngeni up\nThe more important point is LibSQL/Turso. Turso is not just “a local SQLite file with a different name.” LibSQL is SQLite-compatible, but a remote Turso database brings its own connection shape, auth token, protocol, and operational behavior. That’s exactly where a migration tool either feels native or feels like you’re pushing it through a small opening.
\nGeni expects the Turso shape. The documented flow uses DATABASE_URL and DATABASE_TOKEN, it speaks LibSQL, and it can dump a schema.sql snapshot after migrations, which is handy as a review artifact and source-control reference.
On my own Turso projects I like a thin wrapper around Geni. It resolves secrets from whatever store the project uses, splits a composed DSN into DATABASE_URL and DATABASE_TOKEN, points Geni at the right per-database folder, and masks tokens in debug output. That keeps the human command simple:
mise run geni dev app status\nmise run geni prod app up\nOne folder per logical database, paired up/down files, secrets outside the repo, a status check before deploy, and a confirmation prompt before production up or down.
This is the one place the recommendation needs nuance. Goose has been growing, and its current docs list a Turso driver. So the answer is no longer “Goose can’t talk to Turso.”
\nBut “there’s a driver” and “this is the smoothest operational path for my Turso migrations” are not the same claim. The friction I care about isn’t just opening a connection. It’s the whole lifecycle: creating the tracking table, applying safely, transaction behavior, the right remote protocol, auth, status, and a workflow I trust in a short-lived feature branch and in production. For that job I still prefer Geni for LibSQL/Turso, and Goose stays my default for Postgres/MySQL/MariaDB.
\nLightweight SQL migration tools aren’t always enough. I’d start looking at Atlas, Liquibase, Flyway, Sqitch, or an ORM-native system when the problem changes shape:
\nThose are real needs. They’re also real costs. The heavier tool might be worth it, but I wouldn’t start there by default.
\nFor most projects, the better starting point is still: write a small SQL migration, review it in git, run status, apply it, and keep the history boring.
PostgreSQL, MySQL, or MariaDB, I reach for Goose. LibSQL/Turso, I reach for Geni. Not written in Go or Rust? I still consider both, because the CLI boundary matters more than the implementation language. Migrations are an operational concern before they’re an application concern.
\nAnd if the story starts needing drift management, online planning, policy gates, or fleet-wide orchestration, I stop trying to stretch a lightweight tool and pick something heavier on purpose. For everything else, Geni and Goose land right in the sweet spot: small, SQL-first, scriptable, and capable enough to keep schema changes moving without turning migrations into a platform.
\n\n\n", "date_published": "2026-07-08T10:00:00-05:00", "url": "https://llbbl.blog/2026/07/08/geni-vs-goose-for-lightweight.html", "tags": ["DevOps","Database migrations","Geni","Goose","Turso","Libsql","Sql"] } ] }I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.
\n