Paginação de Banco de Dados: Offset versus Cursor em Grandes Tabelas

O Problema Oculto da Paginação em Aplicações Web

Quando desenvolvemos um sistema moderno, é comum precisarmos exibir grandes volumes de dados divididos em páginas. Na superfície, essa tarefa parece simples: basta dizer ao banco de dados para pular um determinado número de registros e trazer apenas os próximos. Na prática, porém, essa escolha aparentemente inofensiva esconde armadilhas de performance capazes de derrubar servidores inteiros à medida que a base de dados cresce. Entender o funcionamento interno dessas consultas é o primeiro passo para projetar sistemas resilientes e escaláveis.

Em termos simples, paginação é a arte de fatiar uma lista gigantesca em pedaços menores para que o usuário ou o aplicativo consigam processá-los sem engasgar. Quando um feed de rede social exibe dez novas postagens ou uma tabela administrativa mostra vinte clientes por vez, existe uma instrução SQL (a linguagem padrão para conversar com bancos de dados relacionais) trabalhando nos bastidores. O modo como construímos essa instrução determina se a nossa aplicação continuará rápida quando a tabela passar de mil para dez milhões de linhas.

Como Funciona a Paginação por Offset e Onde Ela Falha

A abordagem mais tradicional e amplamente ensinada nos tutoriais iniciais utiliza o comando OFFSET combinada com o LIMIT. O termo offset significa literalmente o deslocamento: dizemos ao banco de dados para ignorar os primeiros N registros e retornar os X seguintes. Se pedimos a página cem com vinte itens por página, o banco calcula um offset de dois mil. Para o desenvolvedor, a sintaxe é limpa e intuitiva, facilitando a criação de botões de navegação numéricos como página 1, 2, 3 e assim por diante.

O grande problema técnico é que o banco de dados relacional não possui uma função mágica para pular diretamente para a linha dois mil. Na prática, o motor do banco precisa ler fisicamente todas as duas mil linhas anteriores, descartá-las uma a uma na memória e só então começar a coletar os registros que nos interessam. Quando saltamos para a página cem mil, o banco realiza um trabalho colossal de varredura (conhecido como full table scan ou varredura completa) para entregar um punhado de dados. Na prática, isso significa que quanto mais o usuário navega para o fundo da tabela, mais lenta a consulta se torna, consumindo processamento e memória desnecessários.

-- Exemplo clássico de consulta com Offset e Limit
SELECT id, title, created_at 
FROM posts 
ORDER BY created_at DESC 
LIMIT 20 OFFSET 200000;

Além da degradação severa de desempenho, o Offset sofre de um problema grave de consistência de dados conhecido como efeito fantasma. Imagine que um usuário está na página um e, bem nesse instante, um novo registro é inserido no topo da tabela. Quando esse usuário clica para ir à página dois, o registro recém-criado desloca todos os outros para baixo. O resultado prático é que o usuário acaba visualizando o mesmo item duas vezes em páginas diferentes, ou pior, perde um item que acabou de entrar na faixa de corte. Em sistemas financeiros ou feeds em tempo real, essa volatilidade é inaceitável.

A Alternativa Eficiente: Paginação Baseada em Cursor

Para contornar os gargalos catastróficos do Offset, os engenheiros recorrem à paginação baseada em cursor, também conhecida como paginação baseada em chaves ou keyset pagination. Em vez de dizer ao banco quantos registros ele deve pular, nós fornecemos uma âncora (o cursor) que aponta exatamente para onde paramos. Esse cursor geralmente é o identificador único do último item recebido, como um ID auto-incremental ou um carimbo de data e hora (timestamp) combinado com o ID.

Na prática, o funcionamento lembra a leitura de um livro: em vez de contar cada palavra desde a primeira página para achar o parágrafo atual, você coloca o dedo na última linha lida e continua a partir dali. Quando o cliente solicita a próxima página, ele envia o valor do último cursor recebido. A consulta ao banco de dados utiliza uma cláusula WHERE para filtrar diretamente os registros maiores ou menores que aquele valor, aproveitando os índices da tabela para um salto imediato.

-- Exemplo de paginação por Cursor utilizando um ID de referência
SELECT id, title, created_at 
FROM posts 
WHERE id < 98451 
ORDER BY id DESC 
LIMIT 20;

Essa abordagem elimina por completo a necessidade de varreduras em cascata. Como o banco de dados utiliza índices estruturados em árvore (como as árvores B-Tree), encontrar o registro correspondente ao cursor é uma operação extremamente rápida, independentemente de estarmos no início ou no final de uma tabela com quinhentos milhões de linhas. O tempo de resposta permanece constante e previsível, garantindo estabilidade operacional mesmo sob picos de acesso intenso.

Trade-offs e Desafios Operacionais da Abordagem por Cursor

Apesar de sua superioridade técnica em termos de performance, a paginação por cursor exige mudanças significativas na experiência do usuário e na arquitetura do sistema. O trade-off mais evidente é a perda da navegação arbitrária. Com cursores, você só consegue avançar para a próxima página ou retornar para a anterior de forma sequencial; saltar diretamente da página um para a página duzentos torna-se matematicamente inviável, pois você não possui o cursor intermediário.

Outro detalhe crítico de engenharia é a necessidade de ordenações determinísticas. Se a coluna utilizada como cursor contiver valores duplicados (como dezenas de registros criados exatamente no mesmo segundo), o motor de busca pode perder o encadeamento e omitir dados durante a paginação. Para blindar o sistema contra esse comportamento, os desenvolvedores precisam compor cursores multi-coluna, combinando o timestamp com uma chave primária única, garantindo que cada linha tenha uma identidade absoluta e inconfundível.

Considerações Finais

A escolha entre paginação por Offset e por Cursor não é apenas uma preferência de estilo de código, mas uma decisão arquitetural fundamental que dita a robustez de uma aplicação em larga escala. Enquanto o Offset oferece simplicidade e navegação por páginas numéricas em bases pequenas, ele se torna um veneno silencioso para a performance à medida que a tabela cresce e novos dados chegam. O Cursor, por sua vez, entrega velocidade cirúrgica e consistência absoluta, sacrificando apenas a conveniência dos números de páginas arbitrárias.

Avaliar o volume esperado de dados, o comportamento do usuário e a criticidade da consistência das informações antes de escrever a primeira linha de código evita refatorações dolorosas no futuro. Em ecossistemas modernos de alta concorrência, dominar essas técnicas separa sistemas frágeis daqueles capazes de escalar de forma sustentável e previsível.