Pagination splits a large set of results into discrete pages, so you don't load thousands of records at once. It's essential for performance and usability. Django provides a Paginator class for templates/views, and DRF offers built-in pagination for APIs.
# ❌ loading everything — slow, memory-heavy, bad UX with thousands of rows
articles = Article.objects.()
from django.core.paginator import Paginator
def article_list(request):
articles = Article.objects.all().order_by("-created_at") # ORDER matters for consistent pages
paginator = Paginator(articles, 20) # 20 items per page
page_number = request.GET.get("page") # ?page=2
page_obj = paginator.get_page(page_number) # the requested page
return render(request, "list.html", {"page_obj": page_obj})
<!-- in the template -->
{% for article in page_obj %}
<h2>{{ article.title }}</h2>
{% endfor %}
{% if page_obj.has_previous %}<a href="?page={{ page_obj.previous_page_number }}">Prev</a>{% endif %}
Page {{ page_obj.number }} of {{ page_obj.paginator.num_pages }}
{% if page_obj.has_next %}<a href="?page={{ page_obj.next_page_number }}">Next</a>{% endif %}
The Paginator slices a queryset into pages and get_page() returns a page object with navigation helpers (has_next, next_page_number, etc.) — note it adds LIMIT/OFFSET to the query, so only one page is fetched from the database.
# global default in settings.py
REST_FRAMEWORK = {
"DEFAULT_PAGINATION_CLASS": "rest_framework.pagination.PageNumberPagination",
"PAGE_SIZE": 20,
}
# now list endpoints are automatically paginated, returning:
# { "count": 1000, "next": "...?page=3", "previous": "...?page=1", "results": [...] }
DRF paginates list endpoints automatically once configured, returning page metadata (count, next/previous links) alongside the results — clients navigate via the provided URLs.
PageNumberPagination → ?page=2 (simple page numbers)
LimitOffsetPagination → ?limit=20&offset=40 (flexible offsets)
CursorPagination → opaque cursor; consistent & performant for large/changing data
(avoids OFFSET performance issues on huge datasets)
⚠️ OFFSET-based pagination (page/offset) gets SLOWER on deep pages of huge tables
(the DB must skip OFFSET rows). For very large datasets, CURSOR pagination
(keyset, using a WHERE on an indexed column) is far more efficient.
⚠️ Always ORDER BY a stable field, or pages can be inconsistent/repeat items.
Pagination is essential for building performant, usable applications that handle real data volumes — without it, listing endpoints and pages that load entire tables (potentially thousands or millions of rows) become slow, memory-intensive, and unusable, both straining the database and overwhelming users and clients.
Understanding pagination is everyday practical knowledge: Django's Paginator handles traditional views/templates (slicing querysets into pages with navigation helpers, efficiently fetching only one page via LIMIT/OFFSET), and DRF's built-in pagination handles APIs (automatically paginating list endpoints with metadata and navigation links once configured) — both are needed depending on whether you're building server-rendered pages or APIs.
Knowing how to implement pagination in both contexts is necessary for nearly any data-listing feature.
The performance nuance is particularly valuable senior-level knowledge: standard OFFSET-based pagination degrades on deep pages of very large tables (the database must skip all preceding rows), so cursor (keyset) pagination is the efficient choice for huge or rapidly-changing datasets, and always ordering by a stable field is necessary to avoid inconsistent or duplicated results across pages.
Understanding both the basic mechanics (Paginator, DRF pagination classes) and these performance considerations (OFFSET vs cursor pagination, consistent ordering) is important for building applications that remain fast and correct as data grows — pagination is a ubiquitous requirement, and doing it well, especially at scale, is a practical skill that directly affects application performance and user experience.