I think you have a few options that are rather common to implement. If you have 10,000 records that you need to give back to the client, you can manage this in your MVC application. If you are using Entity Framework and Linq, you can write your business logic to just send back 100 rows per each time the user clicks the next button. This will keep the transmission to the client small and even keep the call from the web server to the SQL server small.
If you don't want to have the user click a next button (i.e. paging) but want do to an infinite scroll style, then just do the same thing, as the user keeps scrolling, just keep calling the Ajax method to send back each 100 rows at a time.
The web server and database server isn't going to choke on 10,000 records; it will be choking going down to the client. Even if you open a socket in Signal R, I think you should ask yourself do I really need to push 10,000 rows all at once to the client?
Think about the Twitter app on a mobile phone, they are sending the data to you as you scroll, they are not sending it all at once. Does that help any?
Updated based on your comment regarding its straight SQL
Here is an example of doing a simple version of paging in SQL:
DECLARE @intStartRow int;
DECLARE @intEndRow int;
SET @intStartRow = (@intPage -1) * @intPageSize + 1;
SET @intEndRow = @intPage * @intPageSize;
WITH blogs AS
(SELECT strBlogName,
ROW_NUMBER() OVER(ORDER BY intID DESC) as intRow,
COUNT(intID) OVER() AS intTotalHits
FROM tblBlog)
SELECT strBlogName, intTotalHits FROM blogs
WHERE intRow BETWEEN @intStartRow AND @intEndRow
Source: http://joelabrahamsson.com/my-favorite-way-to-do-paging-with-t-sql/