On the web it can definitely become a performance constraint, unfortunately. Frameworks can fold under even this number of rows if you're, for example, re-rende

On the web it can definitely become a performance constraint, unfortunately. Frameworks can fold under even this number of rows if you're, for example, re-rendering your entire VDOM tree on every keystroke in an input field. This part can be optimized around fairly easily if you know how, but then the next barrier is number of DOM nodes (specifically, the layout calculations that may have to be done on them when even something seemingly unrelated on the page changes). Depending on the complexity of your rows and what else may be going on on the page, you're probably still confined to the triple-digits if you want smooth performance. Source: I spend a couple years wrestling constantly with these sorts of problems in a React-based toolset we were developing. One strategy I've used before to improve the user experience and help people miss Ctrl+F less is to load the full data set into memory, even if only a small slice of it is actually rendered at a time, and then do all paging/searching/sorting/filtering client-side. JavaScript has no issue handling six digits of items this way, and it keeps things really snappy.