De acordo com os limites do PostgreSQL, é "250 - 1600 dependendo dos tipos de coluna". Veja a nota abaixo da tabela. Os tipos de coluna afetam isso porque no PostgreSQL as linhas podem ter no máximo 8kb (uma página) de largura, elas não podem abranger páginas. Valores grandes em colunas são aceitáveis ​​porque o TOAST lida com isso, mas há um limite para quantas colunas você pode ajustar que depende da largura dos tipos de dados não TOASTed usados.

(Estritamente, isso se refere a colunas que podem ser armazenadas em linhas no disco; as consultas podem usar conjuntos de colunas mais amplos do que isso. Não recomendo confiar nisso.)

Se você está pensando em se aproximar dos limites da coluna, provavelmente terá problemas.

Mapear planilhas para bancos de dados relacionais parece ser a coisa mais simples do mundo - mapear colunas para colunas, linhas para linhas e pronto. Direita? Na realidade, as planilhas são enormes monstros de forma livre que não impõem nenhuma estrutura e podem ser realmente difíceis. Bancos de dados relacionais são projetados para lidar com lotes mais linhas, mas a um custo; no caso do PostgreSQL, parte desse custo é uma limitação da largura que deseja que essas linhas sejam. Ao se deparar com planilhas criadas pelo Joe User isso pode ser um problema real.

Uma "solução" é decompô-los em EAV, mas isso é indescritivelmente lento e feio de se trabalhar. As melhores soluções estão usando matrizes sempre que possível, tipos compostos, hstore , json, xml, etc.

No final, porém, às vezes a melhor resposta é analisar a planilha usando uma planilha.