I was wondering what is the reason behind pagination? Is it used because it lessens the burden on the servers since we would technically limit the amount of rows returned per page?

I wanted to do something without pagination but given that I am new to this (I am an amateur) started wondering if its OK technically or not.

  • Do you really want to wait for your browser to download and render thousands of rows of questions you don't care about when you click "Questions" on this site? – Jeremy Oct 31 '11 at 13:22
  • 3
    pagination is more for humans than DB's. – Malfist Oct 31 '11 at 13:27

There are a number of reasons for having pagination, reducing server load is just one. However, Stephen Orr raises a valid point - you still need to find the amount of data first. You have to make sure that that query is quick and doesn't unduly load your server.

Other reasons include:

  • Reducing the amount of data returned to the client in one go. If you have a lot of data this could take some considerable amount of time and take up a lot of memory.
  • The user often isn't interested in all the data, but only the most recent (say). By returning only a couple of pages of data you aren't getting data the user is never going to see.

In both of these cases you don't want to make the user wait - either for data they aren't going to view, or for all the data when they could be getting one with processing some of it.

  • 2
    +1 I was writing something similar, but you were too fast. Let me just add that paginating content is also (ab)used as a way to show more adds. – yannis Oct 31 '11 at 12:20
  • You can also create pages without having to find out how many pages there are, knowing there is more data than fits the current page is good enough. – Carlo Kuip Oct 31 '11 at 13:45

It varies depending on implementation.

It will speed up rendering of a page, but it won't necessarily reduce the load on the server. Most naive pagination algorithms need to perform a query first to decide how many pages there should be, then query again to get the "paged" result set.

  • Most naive pagination algorithms need to perform a query first to decide how many pages there should be: But the accumulated stress on the db of the count query and the get paginated result query is almost always far less than a get everything query in a common scenario (with a nicely structured relational database) – yannis Oct 31 '11 at 12:28
  • @YannisRizos, absolutely. I've just seen the dark side of this, with an incredibly badly structured relational database (many of our queries JOIN 7 or 8 different tables to get a result). – Steve Hill Oct 31 '11 at 16:09
  • @YannisRizos: define "stress on the db". You're still shoving two queries across the line. Are you paginating in the query (a rowcount super-select), or caching results in another tier? There are way too many variables to say there is too much db stress. I would contend that properly done in a transactional sense (do you allow a dirty read/inconsistent count in pages?) increases db "stress"/load but simplifies programming. – Jé Queue Oct 31 '11 at 16:55
  • @Xepoch I didn't say too much stress, just that any count plus a limited select < full select. And that's only for common scenarios on well structured relational dbs. – yannis Oct 31 '11 at 20:11

The most value you gain from pagination is enhancing the speed of your application by:

1 - Limiting data transmitted between the client and the server. There is no point to read 1000000 customers if the user is looking for 10 of them.

2- Speeding the query performance significantly by retrieving only rows that can fit in a user's view. There is no point to read 1000000 customers if the user will look at the first 10 customers.

3 - Pagination helps by providing more fresh data. If your application shows many data rows and your application domain requires lots of update to data rows in the displayed table, chances are that by the time you go to page 20 of the list of pages, the data on some of the rows would have been changed. Think of an application that reads stock prices or available rooms in a hotel. Retrieving old data and placing it on the client is of no use.

Pagination is one strategy that in combination with filtering and your understanding of how the end user needs from the particular scenario (which is expected to lead to a good design to serve this need) will greatly enhance the application specially when several users are hitting the database concurrently.

Pagination is not always trivial to program. In some cases it is simple but it is sometimes very complex to write so that the SQL query executes without performing a full table scan. This of course depends on your indexes, filter condition and your Where statement.


Pagination, to my mind, is the mother of all premature optimisations. It is absolutely ok to write your site without pagination.

If you find, after release, that you are loading too much data in one call, or that your users are having to wait for information that they do want because it's busy loading data they don't want, go ahead and write an Ajax solution which only loads the page as people scroll down (see: Twitter, Tumblr, Google image search).

Edit: The second paragraph above was written with the assumption that a common response would be "but if you know you are going to paginate at some point, you may as well do it early, rather than waste time developing something you are going to throw away."

As well as being the mother of all premature optimisations, I think that pagination is a UX nightmare and that there are better solutions which wouldn't require much extra development on top of the complete page.

Despite the number of downvotes, I am leaving this answer here because I stand by the sentiment, even though it may not have been my best writing.

  • 5
    I strongly disagree with this statement, pagination isn't for optimizing the DB, it's about providing data in manageable chunks to humans. Would you be able to read Harry Potter if it was all on one page? Would you be able to file taxes if the Tax Code was all on one page? – Malfist Oct 31 '11 at 13:26
  • @Malfist: The only reason you couldn't handle those things on one page is because the page itself would be too big. This is not an issue in web pages. Hence the sites I've cited have found better solutions to pagination, while Lolcats currently has nearly 2000 pages which are impossible to paginate in any sensible way. But, it's your downvote, use it as you will. – pdr Oct 31 '11 at 13:34
  • 1
    @Malfist: Also, splitting things up into manageable chunks is fair enough if those chunks don't shift. If I read pages 1-4 then I want to come back next time and read page 5. But in a LOT of cases, paginated websites are lists of items, most-recent first. So when I go back to page 5 later, it's actually showing half of page 3 and half of page 4 from the last time I was there because there's a whole new 1.5 pages in the list. – pdr Oct 31 '11 at 13:44
  • 2
    -1 As I strongly disagree with this as well. I'm not even sure where to start explaining why. – Craige Oct 31 '11 at 13:56
  • 1
    @Craige: Well, ok then. I'm certainly not able to put up much of an argument to that. – pdr Oct 31 '11 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.