As I was building a very large map recently in vanilla Doom, I kept bumping into the various limits of the map format, and being a newbie took some time to work out what the actual limit was, and how to address each one.

While the information is out there, I couldn't find it all in one place, so in the name of helping other people in the future, here's a compilation of what I learned are the typical limits you're going to reach as you expand the geometry of a map, and what's required to successfully compile and run a map of that size.
Up to 32,768 SEGS: Any modern Node Builder to compile, and any source port to run (notwithstanding other limits like Visplanes). Note: you don't know the number of SEGS a map has until you've compiled it.

32,768 to 65,536 SEGS: Any modern Node Builder to compile, but requires limit-removing source port to run, so excludes the really hardcore vanilla ports like Chocolate

65,537 or more SEGS, but 65,536 or fewer Sidedefs: Requires Node Builder that supports extended nodes to compile, i.e. ZDBSP or DeepBSP. Source port compatible with those Node Builders required to run (must be also limit-removing, but AFAIK all are).

65,536 Sidedefs + a varying amount (depends on map), but 65,536 or fewer Linedefs: If you use GZDoom Builder, upon saving it automatically implements Sidedef compression to try to keep the final number under 65,536 (the Sidedef count in GZDB turns red to indicate you've past the limit). The effectiveness of the compression depends on the variety of Sidedefs in the map, but in my (limited) experience it's pretty effective - up to a 50% reduction in the number of Sidedefs. AFAIK the only way to check exactly how effective is to open the WAD in something like Slade after the compression and look how many Sidedefs there are - the final figure must be under 65,536. Same requirements as above needed to compile and run. This is absolutely pushing the limits of BSP.

65,537 or more Linedefs, or 65,537 or more Sidedefs even after compression: Vanilla Doom format no longer works. The only option is to use the UDMF map format instead, and the node builders and source ports that support it. If you've already started building in vanilla map format, check out this thread on how to convert it to UDMF. Generally though, if you know you're creating a map this big, it's better to start with UDMF, as it effectively removes all limits on everything. The downside is the relatively fewer list of compatible source ports.
Note, these are not the only limits: things like Tags, Things, moving Sectors etc. also all have limits that you may hit before the above ones, but the ones listed are the typical pure geometry related ones.

I'm sure most regulars here know all this stuff already (and indeed if I have any of this wrong, please let me know so I can correct it!). I'm more putting this here because it's the kind of thread I was I had been able to find when searching around for this information, and I hope someone down the line who is also struggling with this discovers it and finds it useful.