Nenhum DBMS que eu conheço tem qualquer "otimização" que fará um VARCHAR com um 2^n length tem um desempenho melhor do que um com um max comprimento que não é uma potência de 2.

Acho que as primeiras versões do SQL Server realmente tratavam um VARCHAR com comprimento 255 diferente de um com um comprimento máximo maior. Não sei se ainda é assim.

Para quase todos os DBMS, o armazenamento real necessário é determinado apenas pelo número de caracteres que você coloca nele, não pelo max comprimento que você define. Portanto, do ponto de vista de armazenamento (e provavelmente também de desempenho), não faz diferença se você declarar uma coluna como VARCHAR(100) ou VARCHAR(500) .

Você deve ver o max comprimento fornecido para um VARCHAR coluna como um tipo de restrição (ou regra de negócios) em vez de uma coisa técnica/física.

Para PostgreSQL, a melhor configuração é usar text sem uma restrição de comprimento e uma CHECK CONSTRAINT que limita o número de caracteres para o que sua empresa exige.

Se esse requisito mudar, alterar a restrição de verificação é muito mais rápido do que alterar a tabela (porque a tabela não precisa ser reescrita)

O mesmo pode ser aplicado para Oracle e outros - no Oracle seria VARCHAR(4000) em vez de text no entanto.

Não sei se há uma diferença de armazenamento físico entre VARCHAR(max) e por exemplo VARCHAR(500) no SQL Server. Mas aparentemente há um impacto no desempenho ao usar varchar(max) em comparação com varchar(8000) .

Consulte este link (postado por Erwin Brandstetter como um comentário)

Editar 22/09/2013

Sobre o comentário de bigown:

Nas versões do Postgres anteriores à 9.2 (que não estava disponível quando escrevi a resposta inicial), uma alteração na definição da coluna fez reescrever a tabela inteira, veja, por exemplo, aqui . Desde a versão 9.2, esse não é mais o caso e um teste rápido confirmou que aumentar o tamanho da coluna para uma tabela com 1,2 milhão de linhas levou apenas 0,5 segundos.

Para o Oracle, isso também parece ser verdade, a julgar pelo tempo necessário para alterar o varchar de uma grande tabela coluna. Mas não encontrei nenhuma referência para isso.

Para MySQL o manual diz "Na maioria dos casos, ALTER TABLE faz uma cópia temporária da tabela original ". E meus próprios testes confirmam isso:executando um ALTER TABLE em uma tabela com 1,2 milhão de linhas (o mesmo que no meu teste com o Postgres) para aumentar o tamanho de uma coluna levou 1,5 minuto. No MySQL, no entanto, você pode não use a "solução alternativa" para usar uma restrição de verificação para limitar o número de caracteres em uma coluna.

Para o SQL Server, não consegui encontrar uma declaração clara sobre isso, mas o tempo de execução para aumentar o tamanho de um varchar coluna (novamente a tabela de 1,2 milhão de linhas acima) indica que não ocorre a reescrita.

Editar 24-01-2017

Parece que eu estava (pelo menos parcialmente) errado sobre o SQL Server. Veja esta resposta de Aaron Bertrand que mostra que o comprimento declarado de um nvarchar ou varchar colunas faz uma enorme diferença para o desempenho.