The router migration is the easy part. The 12-hour outages happen somewhere else.
There’s a conversation happening in Go teams right now that goes something like this:
“We need to migrate off Gorilla. It’s been unmaintained since 2022.”
“Yeah. Add it to the list.”
“What list?”
“The list of things we’ll do after we ship this feature.”
And so Gorilla mux stays. Legacy code has a way of surviving well past its expiry date — especially when migrating it means touching routing code that currently works, even if it sits on an unmaintained foundation.
The database migrations question never comes up in that conversation. In 2026, with AI tooling accelerating how fast features ship, that’s the more dangerous half of the problem.
What Actually Happened to Gorilla
For years, Gorilla mux was used in over 90,000 repositories, including major projects like Cilium, Istio, and Open Policy Agent. Then the maintainers called for new contributors. No one answered. The last maintainer was direct about it: no maintainer is better than a bad one. So they archived it.
By 2025, 17% of Go developers were still using gorilla/mux regularly — down from 36% in 2020, but still a massive footprint of legacy projects running on software that hasn’t had a security patch in over two years.
That’s not a knock on the Gorilla team. It’s actually a very honest decision. What it means for you is simpler: if you’re still on Gorilla mux, you’re running a router that will never get a CVE patch. It works today. It will probably work tomorrow. Until it doesn’t, and there’s nobody home.
Most teams migrating off Gorilla land on Chi (if they want to stay close to net/http), Gin (if they want a larger ecosystem), or the standard library’s updated ServeMux after Go 1.22. All reasonable choices for routing. None of them solve the harder question that comes next.
Routing is the easiest part of any migration. You change the router, update a few middleware patterns, run your tests. A good engineer can handle that in a week.
What’s harder is what your database looks like a month after the migration, when the team is shipping new features on top of the new framework.
The Part Nobody Talks About
Migrating a framework eventually means shipping new features on top of it. New endpoints, new schemas, new tables. That’s where the real risk lives.
Code is easy to change. You push a bad feature, you roll it back, you’re done in minutes. Database schemas are not like that. You can’t roll back a dropped column at 3 AM with a git revert. You can try to restore from backup, but as recent history shows, that process has its own failure modes.
Resend, February 2024. A database migration command run locally accidentally pointed at the production environment and dropped all tables. The outage lasted 12 hours. The first restore attempt took 6 hours and failed due to a wrong backup timestamp selection. A second restore had to be started from scratch. Zero errors in the logs before it happened. The migration “ran successfully” — just against the wrong target.
Heroku, June 2023. A foreign key field had been created with a data type too small to reference its primary key. This worked fine until the primary key hit 2.1 billion — integer overflow. The fix required a migration to upsize the foreign key column, which wiped Postgres’s internal query planner statistics. Queries that took milliseconds suddenly took seconds. A partial outage became a complete API failure. Total downtime: just under 4 hours. The schema bug had existed silently for years before it detonated.
GitHub, June 2025. A routine database migration during a scheduled low-traffic window cascaded into a multi-hour platform-wide outage affecting repositories, pull requests, and GitHub Actions for millions of developers. “Routine” is the word that should give you pause. There’s no such thing as a routine migration when the migration process has no built-in coordination, no automatic lock management, and no guaranteed execution order across multiple running instances.
The failure pattern across all three is structural — what the migration process allowed to happen, not what individual engineers did wrong.
The AI Acceleration Problem
This problem isn’t new. What’s new is the speed at which it now compounds.
AI coding tools have changed how fast features ship. A junior engineer who used to take a week to scaffold a new service now ships it in a day. Mostly that’s good. The catch: those same tools are happy to generate schema changes — new tables, new columns, altered constraints — without thinking about what happens when the migration runs against a live database with three replicas, two of them serving traffic.
A coding assistant can rewrite your routing layer without incident. The database schema is a different problem entirely. Migrations need ordering, coordination, and atomicity, and most Go projects — especially the ones that grew up on Gorilla mux — have none of that. They have a migrations/ folder somewhere with SQL files named inconsistently, run manually before deployment, hopefully in the right order.
That’s the gap the Gorilla migration actually surfaces. Not the router. Everything around it that was never set up properly because the framework never asked you to.
What GoFr Actually Does Differently
GoFr handles database migrations as a first-class framework concern, not an afterthought you bolt on with a third-party CLI.
The migration system supports MySQL, PostgreSQL, Redis, ClickHouse, and Cassandra. Here’s what it looks like in practice:
You create a migration file — named with a timestamp to guarantee sort order across filesystems:
// migrations/20240226153000_create_employee_table.go
package migrations
import "gofr.dev/pkg/gofr/migration"
const createTable = `CREATE TABLE IF NOT EXISTS employee (
id int not null primary key,
name varchar(50) not null,
gender varchar(6) not null,
contact_number varchar(10) not null
);`
func createTableEmployee() migration.Migrate {
return migration.Migrate{
UP: func(d migration.Datasource) error {
_, err := d.SQL.Exec(createTable)
return err
},
}
}
You register migrations in a map — ordered by timestamp key, so execution order is deterministic:
// migrations/all.go
func All() map[int64]migration.Migrate {
return map[int64]migration.Migrate{
20240226153000: createTableEmployee(),
}
}
You wire it in main.go — one line:
func main() {
a := gofr.New()
a.Migrate(migrations.All())
a.Run()
}Migrations run on startup, in order, automatically. GoFr records each migration’s version, start time, and duration in a gofr_migrations table. Only migrations that have never run are executed. You don't run a separate CLI command before deployment. You don't hope someone remembered to run it. It just runs, as part of the application lifecycle.
The Multi-Instance Problem
What happens when you deploy to Kubernetes and three pods start simultaneously?
Without coordination, all three pods try to run the same migrations at the same time. Depending on your database and your migrations, this ranges from “probably fine” to “race condition that corrupts your schema state in a way that won’t be obvious for days.”
GoFr handles this with distributed locking built into the migration runner:
- For SQL databases: a dedicated gofr_migration_locks table with a 15-second lock timeout and a heartbeat that refreshes every 5 seconds for long-running migrations
- For Redis: an atomic set-if-not-exists operation with the same timeout and heartbeat pattern
- If a pod crashes mid-migration, the lock expires automatically and another pod picks it up
The Resend incident — three pods, wrong target, dropped tables — would have looked different with coordinated migration execution. Not because the wrong-target bug wouldn’t have existed, but because coordination forces you to treat migrations as controlled, observable events rather than scripts that run in the background and either succeed silently or fail loudly.
Organizing Migrations the Right Way
One pattern mistake catches almost everyone the first time.
The wrong way — one migration per database operation:
return map[int64]migration.Migrate{
20251114000001: createTableUsers(),
20251114000002: createTableMonitors(),
20251114000003: createTableCheckResults(),
20251114000004: createTableIncidents(),
}This looks organized. It isn’t. When you need to revert a feature, you’re reverting four migrations and hoping they were all created together and can be safely undone together. When something goes wrong mid-deployment, your schema is partially in the new state and partially in the old one.
The right way — one migration per feature:
return map[int64]migration.Migrate{
20251114000001: addMonitoringFeature(), // all 4 tables, atomic
}The feature either exists in your schema or it doesn’t. There’s no partial state. This is the same logic behind feature flags in application code — but applied to the database layer where partial states are far harder to recover from.
This is also exactly the kind of thing AI tooling gets wrong by default. Ask a coding assistant to generate migrations for a new feature and it will happily create one file per table. The structure looks clean. The risk is invisible until something needs to roll back.
The Migration That’s Actually Worth Making
The router change will go smoothly. It’s the most visible, the most testable, the easiest to verify.
The harder question is the migration story underneath it. Do your migrations run in a guaranteed order? Are they recorded somewhere queryable? Do they coordinate across multiple instances? Do they run automatically as part of deployment, or does someone need to remember?
For most teams that grew up on Gorilla, the honest answer to several of those questions is no. Not because those teams were careless. Because Gorilla was a router. It gave you routing. Everything else — observability, health checks, migrations — you assembled yourself, or didn’t, because the framework never made it easy.
Gorilla’s usage is declining and will continue to. Teams migrating now have a choice that teams in 2020 didn’t: move to Chi, Gin, or Echo and reassemble all the production infrastructure manually again — observability, migrations, health checks, circuit breakers — or move to a framework where those concerns ship in the box.
The GitHub incident in 2025 was a routine migration on a mature platform. The Heroku incident was a schema bug that existed silently for years before the primary key counter hit its limit. The Resend incident was a wrong-target migration that deleted everything.
All three lacked the structural safeguards that turn migration failures from outages into non-events.
That’s what a proper migration system gives you. Not protection against human error — nothing does that. Protection against human error becoming a 12-hour outage.
GoFr is open source at github.com/gofr-dev/gofr.
Migration documentation at gofr.dev/docs/advanced-guide/handling-data-migrations.
Gorilla Mux Is Dead. And While You Were Migrating, Your Database Became the Real Problem. was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
