Good trick. Will think about it.

To be honest I never use paginate() because I like to cache my results. I do however build a new Paginator (http://laravel.com/docs/pagination) based upon my own cache / query (repository).

What about this answer, using a Cursor instead of Limit

http://stackoverflow.com/a/16935313

I actually don't know if that Cursor answer will work when using order by? I guess I don't fully understand it (and I'm about to leave the office and run for the train, so feeling a little bit stressed when reading it) ;)

Do you think any alternative of the two is more suitable when combining with the query builder and therefore potentially more advanced queries than the examples on stackoverflow?

To answer myself after reading the answers in that stackoverflow thread I now believe neither of the suggestions are any good alternative when using a query builder, since both are considering the primary key id as the only field to order by. Using order by on other columns breaks any indexing possibilities of getting fast results!?

Zenry: maybe cached results are an option. And the paginator you are working on could implement it, and when doing data changes you could trigger a cache refresh?

I use paginator both in the Admin section and on the API (json/xml) that I provide, since it's a good fit for me, it just works great for me in all aspects, rendering links out of the box, since I use Twitter Bootstrap on this project and provides paging info on json/xml output. Everything is simply working as expected except this performance issue on accessing a page on the last half of the paging set.

Look at the following example from this article

SELECT * 
FROM   products 
JOIN (SELECT id 
      FROM   products 
      ORDER  BY date 
      LIMIT  0, 10) AS t ON t.id = products.id; 

It seems this suggest you can implement pagination in laravel by doing the complete query inside the join (even order by etc.), but only selecting id:s, limit/slice it with minimal data and then return the complete data of the table from the limited subset, creating faster queries on large dataset — as the first example I posted, only a bit more clear that it's not only about indexing and that you only order by the primary key — promising in my ears.

Of course that has to be tested and validated. But guess it will improve best on great datasets with a big table with a lot of data in each row. Guess we can't escape that late rows will be returned slower than low ones. But we can look for improvements that can be implemented in the framework if it is good for everyone, I hope. ;)