Page size limits and opt-in pagination behavior in Django REST Framework

Direct Answers

1. PageNumberPagination with page_size_query_param enabled: max_page_size acts as a hard ceiling. If set, any client-requested page size exceeding this value is capped at max_page_size. If max_page_size is None (default), no upper bound is enforced—the client can request arbitrarily large pages.
2. LimitOffsetPagination without max_limit: The framework imposes no built-in cap on the limit query parameter. A client can request ?limit=1000000 and receive the entire queryset, limited only by database or memory constraints.
3. Project-level default recommendation: DRF documentation does not prescribe a default pagination policy. Pagination is opt-in by design; the developer must explicitly configure DEFAULT_PAGINATION_CLASS in REST_FRAMEWORK settings and define bounds (max_page_size or max_limit) per view or globally.

PageNumberPagination Enforcement Details

When you subclass PageNumberPagination and set page_size_query_param = 'page_size', the pagination class reads the query parameter and validates it against max_page_size.

class StandardResultsSetPagination(PageNumberPagination):
    page_size = 20
    page_size_query_param = 'page_size'
    max_page_size = 100  # hard cap

With this configuration, a request for ?page_size=500 returns 100 items. If max_page_size = None (or the attribute is omitted), the same request returns 500 items. The source logic lives in get_page_size() which calls _positive_int() with the max_page_size argument.

LimitOffsetPagination Unbounded Behavior

LimitOffsetPagination uses limit and offset parameters. The get_limit() method checks self.max_limit; if it is None, the raw integer from the query parameter is used without clamping.

class LargeResultsSetPagination(LimitOffsetPagination):
    default_limit = 50
    # max_limit omitted → no cap

A request for ?limit=10000 will attempt to fetch 10,000 rows. This can trigger expensive queries, memory pressure, or timeouts on large tables.

Why DRF Has No Global Default

DRF treats pagination as a safety vs. convenience trade-off that varies by API:

• Small, internal APIs may prefer zero-config full-queryset returns.
• Public APIs require strict bounds to prevent DoS.
• Cursor-based pagination (CursorPagination) is recommended for large, ordered datasets but requires opaque cursors and stable ordering.

The framework ships with DEFAULT_PAGINATION_CLASS = None, forcing an explicit opt-in. This avoids silent performance regressions when a viewset grows.

Verification Steps

1. Create a test view using your pagination class.
2. Request ?page_size=1000 (or ?limit=1000) against a queryset of known size.
3. Inspect len(response.data['results']) (PageNumberPagination) or len(response.data) (LimitOffsetPagination) to confirm capping or lack thereof.

Diagnostic Question

Are you configuring pagination globally in settings.REST_FRAMEWORK['DEFAULT_PAGINATION_CLASS'] or per-view via pagination_class? The location determines where max_page_size / max_limit must be set to take effect.