We were fetching way too much, so I moved the work to the server

Search and pagination worked great in the demo. Twenty rows, filter in the browser, flip pages instantly. Then real data showed up and it got heavy and slow. The problem was that the client was doing the server's job. We fetched a big list, then filtered and paged it in the browser. That means downloading a ton of rows the user will never look at, every single time. So I flipped it. Search and pagination moved server-side. The browser now asks for exactly one page that matches the current filter, and that's all it gets. Ten rows on screen, ten rows over the wire. The real speedup came from the database. I added the right PostgreSQL indexes on the columns we actually search and sort by, so the query stopped scanning the whole table and started jumping straight to the answer. Over-fetching is sneaky because it looks fine until the data grows. The fix isn't a faster network — it's asking for less. Let the database do what databases are good at, and only send the client what it's about to show. Pages got light, queries got fast, and the browser stopped doing homework that wasn't its.