Ningún DBMS que conozco tiene ninguna "optimización" que haga un VARCHAR con un 2^n la longitud funciona mejor que una con un max longitud que no es una potencia de 2.
Creo que las primeras versiones de SQL Server en realidad trataban un VARCHAR con una longitud de 255 de forma diferente a uno con una longitud máxima superior. No sé si esto sigue siendo así.
Para casi todos los DBMS, el almacenamiento real que se requiere solo está determinado por la cantidad de caracteres que ingresa, no por el max longitud que defina. Entonces, desde el punto de vista del almacenamiento (y probablemente también del rendimiento), no importa si declara una columna como VARCHAR(100) o VARCHAR(500) .
Deberías ver el max longitud proporcionada para un VARCHAR columna como una especie de restricción (o regla comercial) en lugar de algo técnico/físico.
Para PostgreSQL, la mejor configuración es usar text sin una restricción de longitud y un CHECK CONSTRAINT que limita el número de caracteres a lo que requiera su negocio.
Si ese requisito cambia, alterar la restricción de verificación es mucho más rápido que alterar la tabla (porque no es necesario volver a escribir la tabla)
Lo mismo se puede aplicar para Oracle y otros; en Oracle sería VARCHAR(4000) en lugar de text aunque.
No sé si hay una diferencia de almacenamiento físico entre VARCHAR(max) y por ejemplo VARCHAR(500) en el servidor SQL. Pero aparentemente hay un impacto en el rendimiento cuando se usa varchar(max) en comparación con varchar(8000) .
Consulte este enlace (publicado por Erwin Brandstetter como comentario)
Editar 2013-09-22
Con respecto al comentario de Bigown:
En las versiones de Postgres anteriores a la 9.2 (que no estaba disponible cuando escribí la respuesta inicial), un cambio en la definición de la columna did reescribir toda la tabla, ver por ej. aquí . Desde la versión 9.2, este ya no es el caso y una prueba rápida confirmó que aumentar el tamaño de columna para una tabla con 1,2 millones de filas solo tomó 0,5 segundos.
Para Oracle, esto también parece ser cierto, a juzgar por el tiempo que lleva alterar el varchar de una tabla grande columna. Pero no pude encontrar ninguna referencia para eso.
Para MySQL el manual dice
"En la mayoría de los casos, ALTER TABLE hace una copia temporal de la tabla original ". Y mis propias pruebas confirman que:ejecutando un ALTER TABLE en una tabla con 1,2 millones de filas (lo mismo que en mi prueba con Postgres) aumentar el tamaño de una columna tomó 1,5 minutos. Sin embargo, en MySQL puede no use la "solución alternativa" para usar una restricción de verificación para limitar la cantidad de caracteres en una columna.
Para SQL Server, no pude encontrar una declaración clara sobre esto, pero el tiempo de ejecución para aumentar el tamaño de un varchar columna (nuevamente la tabla de 1,2 millones de filas de arriba) indica que no tiene lugar la reescritura.
Editar 2017-01-24
Parece que estaba (al menos parcialmente) equivocado sobre SQL Server. Consulte esta respuesta de Aaron Bertrand
que muestra que la longitud declarada de un nvarchar o varchar columnas hace una gran diferencia para el rendimiento.
