All posts

How to Add a New Column Without Downtime in PostgreSQL and MySQL

Adding a new column is one of the most common schema migrations in application development. Done wrong, it can lock tables, slow queries, and cause downtime. Done right, it happens in seconds with zero disruption. Start with clarity: define the column name, data type, default value, and constraints. A NOT NULL column with no default will fail on creation if rows already exist, so decide early whether to allow nulls or backfill in a staged deployment. For relational databases like PostgreSQL or

Free White Paper

Just-in-Time Access + PostgreSQL Access Control: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

Adding a new column is one of the most common schema migrations in application development. Done wrong, it can lock tables, slow queries, and cause downtime. Done right, it happens in seconds with zero disruption.

Start with clarity: define the column name, data type, default value, and constraints. A NOT NULL column with no default will fail on creation if rows already exist, so decide early whether to allow nulls or backfill in a staged deployment.

For relational databases like PostgreSQL or MySQL, the safest process is:

  1. Add the new column as nullable.
  2. Backfill data in small batches to avoid long-running locks.
  3. Apply constraints and defaults in a subsequent migration.

In PostgreSQL, an ALTER TABLE ... ADD COLUMN is fast if it’s nullable with no default. Adding a DEFAULT with NOT NULL to a large table in one step can rewrite the table and block writes. Use ALTER TABLE followed by an UPDATE in controlled chunks, then apply constraints.

Continue reading? Get the full guide.

Just-in-Time Access + PostgreSQL Access Control: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

In MySQL, online DDL for adding a new column depends on the storage engine and configuration. With InnoDB, ALGORITHM=INPLACE can prevent a full table copy, but test on staging to confirm runtime and impact.

For large datasets, consider feature flags to gate application reads/writes to the new column until the migration finishes. This keeps the application logic separate from schema changes and prevents partial writes from breaking workflows.

Think through indexes. Adding an index to the new column can be more expensive than adding the column itself. Create indexes after backfill, possibly with CONCURRENTLY in PostgreSQL or online index creation in MySQL to avoid blocking queries.

The goal: new column in production, no downtime, no data loss, no surprises in query plans.

You can run this kind of schema change with confidence and see it in action in minutes—head over to hoop.dev and make your next new column deployment smooth and safe.

Get started

See hoop.dev in action

One gateway for every database, container, and AI agent. Deploy in minutes.

Get a demoMore posts