Gerador de ALTER TABLE SQL

SQL ALTER TABLE: evoluindo esquemas sem perder dados

O ALTER TABLE é o comando DDL que modifica uma tabela existente — adicionando, removendo, renomeando, mudando tipo ou ajustando constraints de colunas — sem precisar dropar e recriar. É o burro de carga de toda migration de banco em toda aplicação de longa vida: esquemas evoluem, requisitos mudam, e o ALTER TABLE é como você traz uma tabela antiga para o presente sem perder dados. Usado sem cuidado em uma base de produção movimentada, porém, o mesmo comando consegue lockar a tabela por minutos e derrubar um serviço inteiro. Esta página cobre as operações, diferenças entre dialetos, comportamento de locks e padrões de online migration que todo dev backend precisa conhecer.

Operações principais

• ADD COLUMN — anexa uma nova coluna ao final da linha.
• DROP COLUMN — remove a coluna e todos os seus dados (irreversível sem backup).
• RENAME COLUMN / RENAME TO — renomeia uma coluna ou a tabela inteira.
• ALTER COLUMN / MODIFY COLUMN — muda tipo, nulabilidade ou default de uma coluna.
• ADD CONSTRAINT / DROP CONSTRAINT — gerencia PRIMARY KEY, FOREIGN KEY, UNIQUE e CHECK.
• ADD INDEX / DROP INDEX — geralmente escritos como CREATE INDEX / DROP INDEX separados.

Sintaxe por dialeto

-- PostgreSQL
ALTER TABLE usuarios ADD COLUMN idade INTEGER;
ALTER TABLE usuarios ALTER COLUMN idade TYPE BIGINT USING idade::BIGINT;
ALTER TABLE usuarios RENAME COLUMN nome TO nome_completo;
CREATE INDEX CONCURRENTLY idx_usuarios_email ON usuarios(email);

-- MySQL / MariaDB
ALTER TABLE usuarios ADD idade INTEGER, ALGORITHM=INPLACE, LOCK=NONE;
ALTER TABLE usuarios MODIFY COLUMN idade BIGINT;
ALTER TABLE usuarios CHANGE COLUMN nome nome_completo VARCHAR(100);

-- SQL Server
ALTER TABLE usuarios ADD idade INT NULL;
ALTER TABLE usuarios ALTER COLUMN idade BIGINT NOT NULL;
EXEC sp_rename 'usuarios.nome', 'nome_completo', 'COLUMN';

-- SQLite (muito limitado)
ALTER TABLE usuarios ADD COLUMN idade INTEGER;
ALTER TABLE usuarios RENAME COLUMN nome TO nome_completo;  -- desde 3.25
-- Qualquer outra coisa: CREATE nova, INSERT SELECT, DROP antiga, RENAME.

Locks, downtime e online schema changes

O ALTER TABLE pode segurar um lock exclusivo que bloqueia leituras e escritas durante toda a operação. Em uma tabela de 500 GB, isso pode ser horas. O playbook seguro varia por engine:

• PostgreSQL: a maioria dos ADD COLUMN sem default é instantânea desde a 11 (metadata-only). Mudar tipo ainda reescreve a tabela. Sempre crie índices com CREATE INDEX CONCURRENTLY. Para migrations pesadas use pg_repack ou pg-osc.
• MySQL / MariaDB: a hint ALGORITHM=INPLACE, LOCK=NONE ativa DDL online quando suportada. Para operações não suportadas, use pt-online-schema-change (Percona Toolkit) ou gh-ost (GitHub) — ambos constroem uma tabela sombra e fazem o switch atômico.
• SQL Server: a Enterprise suporta ONLINE = ON para muitas operações; a Standard não.
• SQLite: não há DDL online — o banco fica locked durante toda a operação. Mitigado pelo caso de uso típico do SQLite (escritor único, datasets pequenos).

Migrations compatíveis: expand e contract

Em um deploy sem downtime você não pode quebrar a versão antiga do app enquanto a nova está sendo entregue. A receita clássica é expand-contract:

1. Expand: adicione a coluna nova como nullable, faça deploy do código que escreve em ambas (velha e nova).
2. Backfill: copie os dados da antiga para a nova em batches, com throttle.
3. Switch reads: faça deploy do código que lê apenas da coluna nova.
4. Contract: aperte a constraint (NOT NULL) e dropa a coluna antiga.

Cada passo é independentemente seguro e rollback-friendly. Renames são especialmente dolorosos porque nenhum engine renomeia coluna sem coordenar com clients; a dança expand-contract permite entregar mudanças equivalentes a rename sem downtime.

Frameworks de migration

Times em produção nunca executam ALTER TABLE ad-hoc. Um framework de migration versiona cada mudança em arquivo, aplica de forma determinística em todos os ambientes e registra quais versões já rodaram. Opções populares: Flyway e Liquibase (JVM), Alembic (Python/SQLAlchemy), Knex.js, Prisma Migrate e TypeORM (Node.js), Rails migrations (Ruby), golang-migrate (Go) e EF Core Migrations (.NET). Todo framework suporta uma migration up e uma down correspondente; bom hábito é escrever o down junto e rodá-lo localmente antes do merge.

FAQ

Quanto tempo o ALTER TABLE demora? Pode variar de milissegundos a horas. Mudanças metadata-only (ADD COLUMN no Postgres 11+) são instantâneas; rewrites completos escalam com a quantidade de linhas.

É reversível? O comando em si não — não existe UNDO ALTER. A reversibilidade vem do passo down do seu framework de migration, que descreve a mudança inversa. DROP COLUMN é destrutivo permanente sem backup.

Vai quebrar minha app em produção? Pode quebrar. Trate toda mudança de schema como mudança de contrato: faça deploy de código compatível primeiro (expand), depois rode a migration, depois faça deploy do código que depende do novo formato e por fim faça o contract.

Posso agrupar várias operações? Sim — a maioria dos dialetos aceita ALTER TABLE t ADD a INT, DROP b, RENAME c TO d. Agrupar é mais rápido porque a tabela é locked uma só vez, mas erros revertem o batch inteiro.

Por que adicionar coluna NOT NULL lockou? O engine precisa checar todas as linhas. Adicione a coluna nullable primeiro, faça backfill e depois adicione NOT NULL em migration separada (Postgres 12+ consegue adicionar NOT NULL instantaneamente se houver default não-volátil).