I think it depends on what do you do on the portal.
Only showing data in portal may not problem with 140,000 records, it would be same as showing it in list view.
If you try to "filter" the portal, or make calculation with it, or sort the portal, 140,000 may be unusable. But sorry I don't have the number what is the limit. It should be different in the file is shared or not.
It really depends on what you are doing the portal data... for example, filtering, sorting, and displaying unstored calcs in the portal can all be very taxing. FileMaker does not load every record in the related table just because you display a portal to that table. Typically it will load the records visible and then a buffer of maybe 15-25.
However, if you sort or count all the portal rows, then you have an issue because FileMaker must process all the records to resolve the command.
So the question is, what are you doing with the portal other than displaying the related data?
It also depends on how many users you have, what data you have in the portal records, how fast the server is... for example at one place we have a portal-based agenda showing 60 portal lines out of 550'000, with 40 users on it, performing well. If you switch to 10 user view, thus showing 10 portals with 60 lines each (all pointing to the same table but with different keys), it still is decent.
I think you answered your own question!
a portal with 140,000 records in it is so slow it's unusable
The GTRR (go to related record) is a FIND, IMO. It is a quick way when there is a relationship to get to just those records without actually using a scripted find. Even a "filtered" portal need not have any records, but a "GTRR" button inside a single-row filtered portal will also "find" the narrowed set of related records.
I believe "display" is the optimum point here. I agree that more than 15-25 related rows and it's probably not even good UI/UX to display a portal. I hate having to scroll more than that.
You posted at 3:20 AM? Are you doing FileMaker at this hour??? That's dedication.
Yeah, I thought the GTTR would be a better way to go as well. With huge amounts of data, taking advantage of indexes in relationships is important regardless of the platform.
Although everyone posted good ideas, I marked your answer as "correct" since it seems to me to match both what I was thinking and what I was observing in terms of performance.
I'm on ET. The grandkid gets up early. 6:20 am? That's normal!