Even for terrain it can be useful to have a duplicate “physics mesh” that you run a decimate modifier on (often terrain is pretty much flat where the player is, and the decimate modifier can reduce the polycount dramatically).
Another trick is to split up the terrain’s physics mesh into “chunks”. That’s what I did in [BGMC 28] To The Surface where I had terrain with 25,000 faces after the decimation (there’s something to be said for auto-generating extremely detailed collision shapes…).
With the terrain as a single object, every single other object in the scene had to run a collision test against all 60,000 vertices, so even a handful of dynamic objects caused performance drop on my laptop. Dividing the 25,000 faces into 16 chunks of ~1600 faces each meant that the objects had to do a bounding box check (cheap to run) against all 16, and then only had to check 1600 faces. (in absolute worst case, you may be within the bounds of four terrain chunks, in which case you have 6400 faces - still better than 3x performance gain).
Making sure you aren’t overly stressing one part of a physics engine is a pretty good technique. Unfortunately, BGE/bullet doesn’t have any good profiling tools, so you have to know a bit about how physics engines work and do it via trial and error. It’s similar to the renderer in some ways: a single million polygon object will run slowly, as will a million single polygon objects. You find the best balance somewhere in between.