According to PostgreSQL Limits it’s “250 – 1600 depending on column types”. See note under the table. The column types affect it because in PostgreSQL rows may be at most 8kb (one page) wide, they cannot span pages. Big values in columns are OK because TOAST handles that, but there’s a limit to how many columns you can fit in that depends on how wide the un-TOASTed data types used are.
(Strictly this refers to columns that can be stored in on-disk rows; queries might be able to use wider column sets than this. I don’t recommend relying on it.)
If you’re even thinking about approaching the column limits you’re probably going to have issues.
Mapping spreadsheets to relational databases seems like the simplest thing in the world – map columns to columns, rows to rows, and go. Right? In reality, spreadsheets are huge freeform monsters that enforce no structure and can be really unweildy. Relational databases are designed to handle lots more rows, but at a cost; in the case of PostgreSQL part of that cost is a limitation to how wide it likes those rows to be. When facing spreadsheets created by Joe User this can be a real problem.
One “solution” is to decompose them into EAV, but that’s unspeakably slow and ugly to work with. Better solutions are using arrays where possible, composite types, hstore, json, xml, etc.
In the end, though, sometimes the best answer is to analyse the spreadsheet using a spreadsheet.