Según los límites de PostgreSQL, es "250 - 1600 según los tipos de columna". Ver nota debajo de la mesa. Los tipos de columna lo afectan porque en PostgreSQL las filas pueden tener como máximo 8kb (una página) de ancho, no pueden abarcar páginas. Los valores grandes en las columnas están bien porque TOAST maneja eso, pero hay un límite en la cantidad de columnas que puede incluir que depende de qué tan amplios sean los tipos de datos sin TOAST utilizados.
(Estrictamente, esto se refiere a las columnas que se pueden almacenar en filas en el disco; las consultas pueden usar conjuntos de columnas más amplios que este. No recomiendo confiar en él).
Si incluso está pensando en acercarse a los límites de la columna, probablemente tendrá problemas.
La asignación de hojas de cálculo a bases de datos relacionales parece la cosa más simple del mundo:asigne columnas a columnas, filas a filas y listo. ¿Derecha? En realidad, las hojas de cálculo son enormes monstruos de forma libre que no imponen ninguna estructura y pueden ser realmente incómodas. Las bases de datos relacionales están diseñadas para manejar muchos más filas, pero a un costo; en el caso de PostgreSQL, parte de ese costo es una limitación del ancho que le gustaría que tuvieran esas filas. Al enfrentarse a hojas de cálculo creadas por Joe User, esto puede ser un verdadero problema.
Una "solución" es descomponerlos en EAV, pero eso es increíblemente lento y feo para trabajar. Las mejores soluciones son el uso de arreglos donde sea posible, tipos compuestos, hstore , json, xml, etc.
Sin embargo, al final, a veces la mejor respuesta es analizar la hoja de cálculo usando una hoja de cálculo.
