Most of the patch data is loaded/updated in on big json blob when you land on the page (in the background)
The search is all client-side with different algorithms on each column, so there's no need to send the search query back to the server (when user enters search terms) and therfore no database query required.... (yet) but your suggestion is quite a creative idea for DB driven searches - but perhaps overkill at this stage. However, I just need to extend each column's search function a little bit in javascript, probably a few lines of additional code on each column, without having to think about database design..
If you are interested in the table component I used, have a look at https://material-table.com/#/docs/features/filtering which extends the UI framework https://material-ui.com/ which runs in a React.js app (Single page app). You can check the code here https://github.com/spookycookie27/NordPatches
Anyway, basically it's better the browser does as much of the processing as possible (like searches) rather than the backend server or database server .... the main concept behind 'cloud' computing .... get the client's PC, browser, backend server and database server all working in harmony, and use the client's PC processor as much as possible

If the library gets too big, like maybe in 10 years, I might have to move the search logic onto the server/database (more traditional) and use SQL search like you suggest... or if i can't nail it with javascript
