Database change review process for growing startups

Why database changes fail at deploy time

Most deploy failures do not start with a big redesign. They start with a small edit that looked safe in a pull request. A renamed column, a new constraint, or a quick migration can turn a normal release into a long night.

Code is easy to read in review. Database behavior is not. A query that works fine on a laptop with 2,000 rows can crawl in production with 20 million. A migration that finishes in seconds locally can lock writes long enough to break checkout, signup, or internal tools.

Startups run into this all the time. Someone ships a feature fast, someone else reviews the code, and everyone assumes the database part is routine. Nobody stops to ask what the change does to old data, background jobs, or the previous app version that may still be running during deploy.

Most of the pain comes from a familiar set of mistakes. Teams drop or rename a column while some code still reads it. They add a NOT NULL rule before old rows meet it. They miss an index, or add the wrong one, and a fast page turns into a timeout. They run a backfill in one large transaction and slow the whole app. Then they discover that rolling back the app does not undo changed data.

Index risk often slips through because it is less visible than app code. Reviewers notice a new endpoint, but they may not check whether its filters match an index. Migration risk slips through for the same reason. Teams read the SQL, see that it looks short, and assume it is safe.

Pick one owner for the final call

A startup should name one person who can say yes or no before a database change ships. Without that, review turns into a group chat. Risky edits slip through because everyone assumes someone else checked them.

Shared ownership sounds fair, but it often breaks down in practice. One engineer reviews the migration file, another looks at app code, and nobody decides whether the release is actually safe today. By the time deploy starts, open questions show up under pressure. That is when bad calls happen.

The final owner should stay close to daily product and engineering work. In most startups, that person is the tech lead, engineering lead, senior engineer, or CTO who understands the schema, traffic patterns, and release pace. They do not need to write every migration. They do need enough context to judge risk.

The founder should step in when the change can hurt the business beyond engineering. That usually means a migration that may cause visible downtime, change billing data, affect customer reporting, touch retention rules, or force a tradeoff between speed and safety. If the impact reaches customers, revenue, or contracts, the founder needs a voice.

The owner should be able to answer a few plain questions quickly: What can break if this ships today? Can we roll it back without data loss? Do we need a slower rollout or a maintenance window? Who will watch the system after deploy?

If the person with final say sits too far from the code, they approve changes on trust alone. If they sit too far from product, they may protect the database while missing business risk. The role works best when one person can see both sides clearly enough to make the call.

This does not need a formal ceremony. It needs an explicit name in the release process. Once one person owns the final call, the team moves faster because nobody wastes time guessing who is responsible.

Split the work across clear roles

One person should not carry every database decision, even in a small startup. Clear roles catch different problems early and make deploy day much less dramatic.

The engineer who writes the change starts the process. Their job is to explain why the table, column, constraint, or index needs to change now, what problem it solves, and why a simpler option will not work. If they cannot explain that in a few plain sentences, the team should pause.

A second engineer should review the SQL itself. This is not a style review. It is a check for names people will still understand six months later, queries that match the app logic, and migration steps that will not leave the schema half-finished.

Someone who owns infrastructure or operations should look at runtime risk. That means backups, expected load, lock time, deploy timing, and how the change behaves on a busy system. A migration that looks harmless in development can slow writes for minutes in production. That is long enough to hurt users.

Product also has a role here. Someone close to users should confirm what changes on screen, in reports, in exports, or in admin flows. A renamed field can confuse support, break a dashboard, or make a familiar workflow feel wrong even if the schema change itself is technically fine.

Each role is checking a different thing:

• Why do we need this change now?
• Does the SQL make sense?
• Can production handle it safely?
• What will users notice?
• Who gives the final yes?

The final owner should approve the full plan, not just the migration file. If one person wears two hats, that is fine. Small teams do that all the time. What matters is that the responsibility stays clear and nobody discovers risk for the first time during deploy.

Decide which changes need extra review

Not every schema edit needs the same path. If your team treats "add a column" and "drop a column" as equal, review gets noisy and the risky work hides inside it.

A simple rule works well. Changes that only add room for new data usually need normal review. Changes that alter, remove, or rewrite existing data need extra review from the person who owns deploy safety.

Normal review usually covers lower-risk edits such as a new table, a nullable column, or a column the app does not use yet. These still need a quick check for naming, defaults, and whether the app can handle empty values.

Extra review should start when a change can break running code or slow the database during deploy. Column renames, type changes, drops of tables or columns, new or removed indexes, and large backfills all belong in that bucket.

A rename looks harmless on paper, but old queries, background jobs, and reports can still call the old name. A type change can fail halfway if old rows do not fit the new format. Index changes deserve the same caution. Adding an index can put heavy load on a busy table, and removing one can turn a fast query into a slow page.

Large backfills need review before merge, not ten minutes before release. If a migration will touch millions of rows, the team should ask how long it runs, whether it blocks writes, and whether it can run in batches.

Destructive steps should almost never ship in the same release as the app change that replaces them. A safer pattern is simple: add the new field, ship code that uses it, copy the data, confirm the new path works, and remove the old field in a later release.

Fast teams do not need a heavy process here. They need clear labels. If every database pull request is marked normal review, extra review, or separate release, people spot risk early instead of during deploy.

Use the same review path every time

A good review flow does not need a committee. It needs a short path that every engineer follows before code reaches production.

Start with one rule: nobody edits production by hand. Every schema change, index update, and data backfill should live in a migration file in the repo. That gives the team a record of what changed, when it changed, and how to repeat it in staging and production.

Each migration should also include a short note in plain language. Keep it brief. Say what problem it solves, which tables it touches, and what load you expect during rollout. Even one sentence about row count or write traffic can catch trouble early. Adding an index to a quiet table is one thing. Changing a large table under constant write load is another.

One other engineer should review the migration before merge. That review should go beyond SQL syntax. The reviewer should ask whether the change locks a hot table, rewrites too much data, breaks older code paths, or depends on a release order that nobody has written down.

Before merge, run the migration on staging or on recent sample data that looks like production. Tiny test datasets hide bad plans. If your production table has 40 million rows, a test with 2,000 rows tells you almost nothing about runtime or locking.

A simple review path usually looks like this:

• Write the migration and attach a short note.
• Ask one engineer to review both code and risk.
• Run it on staging or recent production-like data.
• Choose the deploy window before merge.

That last step matters more than teams expect. If a migration may slow writes, do not merge it on Friday afternoon and hope for the best. Pick a window when the team is awake, traffic is lower, and someone can watch the database.

Lean teams still need this discipline. In AI-augmented engineering setups, fewer people may touch operations day to day, so a clear path matters even more. Five calm minutes before merge can save hours of repair during deploy.

Plan deploy and rollback together

A deploy plan should answer one direct question: what happens to real data while this change runs?

If a table has a few thousand rows, you may get away with a quick edit. If it has 50 million, the same edit can lock writes, slow reads, or leave the app half-working for longer than anyone expected.

Start with rough numbers. Count the rows the migration will touch. Estimate how long the query will run on production hardware, not on a laptop copy with tiny data. For products with users across many countries, even a 10-minute lock can hurt because there is no quiet hour for everyone.

Large changes usually go better when you split them. Add a new column first. Let the app write to both old and new fields for a while. Backfill in small batches. Switch reads only after the new path looks stable. Drop the old column in a later release. It takes more than one deploy, but it avoids the kind of surprise that breaks trust in your release process.

The app also needs a transition plan. If one version of the app expects the old schema and the new migration changes it all at once, you create a race during deploy. Backward compatibility first, cleanup later, is the safer pattern.

Write the rollback plan before deploy day. Do not assume the team will improvise well under pressure. Put the exact commands, the person who can approve the stop, and the data limits in writing.

Your stop points should be just as clear:

• Stop if the migration runs past the agreed time limit.
• Stop if write queues start to grow.
• Stop if error rates jump after the app switches.
• Stop if rollback takes longer than expected.

Lean teams can keep uptime very high, but only when changes stay boring. Boring deploys come from small releases, compatibility during the switch, and a rollback plan nobody has to invent at 2 a.m.

A simple example from a growing product

A small SaaS team wants to add team invites so one account owner can bring coworkers into the app. One engineer suggests a straightforward database update: add team_id and invited_by_user_id to the users table, then create two indexes so team member lists and invite lookups stay fast.

At first glance, that looks like a normal feature task. The risk hides in the migration plan. The same draft also includes a backfill that updates every existing user row in one run so older accounts fit the new model.

A reviewer reads the plan and stops there. The deploy is scheduled for peak traffic, when users are signing in, sending invites, and refreshing dashboards. A full backfill at that hour could lock rows, slow queries, and turn a small release into a messy one.

So the team rewrites the plan before production ever sees it. They ship in four steps:

1. Add the new columns.
2. Backfill old rows in small batches during lower traffic.
3. Switch the app to read and write the new fields.
4. Clean up old code and unused columns after the new path is stable.

Nothing dramatic happens during release, and that is the point. The app keeps running, support gets no flood of complaints, and the team can watch each step instead of guessing.

That is what review should do. It should catch risk while the change is still easy to fix. A short schema review often saves more time than a rushed deploy ever will.

Mistakes teams repeat

Most teams do not fail because the SQL is fancy. They fail because they mix risky work into a normal release and assume someone else checked the details.

One common mistake is editing production data by hand. A developer opens a console, runs an update, fixes the immediate issue, and moves on. Two weeks later, nobody remembers what changed, which rows changed, or whether the same fix needs to run in staging and other environments. If data needs a manual fix, write it down, review it, and run it like any other change.

Teams also bundle schema work with unrelated app updates. That feels efficient, but it makes review sloppy. If one release includes a new feature, a refactor, two config changes, and three migration files, people focus on whether the app still works. They miss the database risk.

Indexes cause a quieter kind of trouble. Someone adds a new index to speed up reads, but nobody checks what it does to writes. On a busy table, extra index work can slow inserts and updates enough to hurt the whole app. The problem often appears only under real traffic.

Old columns get dropped too early all the time. A team renames a field, updates most of the code, and removes the old column in the same release. Then one background job, report, or admin screen still reads the old name. The deploy succeeds, but errors start a few minutes later.

The safest pattern is boring: add the new column, switch reads and writes in the app, confirm nothing uses the old column, and drop it later.

Rollback plans also stay vague until the deploy starts. That is too late. If a migration fails halfway, the team should already know whether they will restore from backup, run a reverse migration, or keep the schema and roll the app forward. "We will figure it out live" is not a plan. It is how a ten-minute release turns into a long night.

A short pre-deploy checklist

The last five minutes before deploy should feel uneventful. If people are still arguing about ownership, lock risk, or rollback steps at that point, the team started too late.

Name the people first. One person should own the final call, and one reviewer should challenge the plan before it reaches production. In a small startup, that owner may be the tech lead, CTO, or a fractional CTO. The reviewer can be another engineer who did not write the migration.

Then check the migration itself. Run it against data that looks like production, not a tiny local sample. A migration that finishes in eight seconds on a laptop can hold locks much longer on a busy table.

Rollback needs the same care as the forward change. If the team cannot explain how to undo the change in plain language, the deploy is not ready. Sometimes rollback means restoring code and data. Sometimes it means a follow-up migration. Either way, write it down.

Last, pick the deploy window on purpose. A quiet period lowers the chance that a slow migration blocks signups, billing, or internal tools. If traffic never really drops, make the change smaller, split the migration, or delay the release.

A short checklist is enough:

• Write down the owner and reviewer.
• Test the migration on realistic data.
• Write rollback steps and who will run them.
• Check lock risk, index build time, and query load.
• Choose a deploy window that gives the team time to watch it.

If any part is missing, wait. Ten extra minutes before deploy can save hours of repair later.

What to do next

Start small. Most teams do not need a heavy process. They need one page that says who reviews schema edits, who approves risky migrations, and what must be checked before deploy.

Write that page this week. Keep it plain enough that a new engineer can read it in five minutes and follow it without guessing. If a rule is hard to explain, it is probably too complex.

A simple starting point is enough. Name one owner for the next database release. Require review for schema changes, new indexes, and destructive migrations. Ask for a short rollback note before deploy. Block production deploys if nobody has tested the migration on realistic data.

After that, spend an hour looking backward. Pull up your last three to five migrations and mark the weak spots. Maybe one changed a large table with no timing estimate. Maybe another added an index without checking write impact. Maybe nobody wrote down how to undo a failed change. Fix those gaps first.

Then assign one person to make the final call on the next release. That does not mean they do all the work. It means one person checks that the plan is clear, the risk is understood, and the team is not learning about a dangerous change during deploy.

Fast teams often skip this because shipping feels urgent. That is usually a mistake. A few extra minutes of review can save hours of downtime, rollback stress, and late-night debugging.

If your team moves quickly and still lacks release habits, outside help can be useful. Oleg Sotnikov writes and works in this area on oleg.is, where he helps startups and small companies as a Fractional CTO and advisor. That kind of support can help a team set simple rules for migrations, indexes, and deploy safety without turning the whole process into paperwork.

Pick one migration on your roadmap now, assign the owner, and write the rollback note before anyone starts coding. That is a good test of whether your process is real.