Enligt PostgreSQL Limits är det "250 - 1600 beroende på kolumntyper". Se not under tabellen. Kolumntyperna påverkar det eftersom rader i PostgreSQL kan vara högst 8kb (en sida) breda, de kan inte sträcka sig över sidor. Stora värden i kolumner är OK eftersom TOAST hanterar det, men det finns en gräns för hur många kolumner du får plats i som beror på hur breda de icke-ROSTADE datatyperna som används är.
(Detta syftar strikt på kolumner som kan lagras i rader på disken; frågor kanske kan använda bredare kolumnuppsättningar än detta. Jag rekommenderar inte att du litar på det.)
Om du ens funderar på att närma dig kolumngränserna kommer du förmodligen att få problem.
Att kartlägga kalkylblad till relationsdatabaser verkar vara det enklaste i världen - mappa kolumner till kolumner, rader till rader, och gå. Rätt? I verkligheten är kalkylblad enorma friformsmonster som inte upprätthåller någon struktur och kan vara riktigt obehagliga. Relationsdatabaser är designade för att hantera massor fler rader, men till en kostnad; i fallet med PostgreSQL är en del av den kostnaden en begränsning av hur breda den vill att raderna ska vara. När du står inför kalkylblad skapade av Joe User kan detta vara ett verkligt problem.
En "lösning" är att bryta ner dem till EAV, men det är obeskrivligt långsamt och fult att arbeta med. Bättre lösningar är att använda arrayer där det är möjligt, sammansatta typer, hstore , json, xml, etc.
I slutändan är dock ibland det bästa svaret att analysera kalkylarket med hjälp av ett kalkylblad.