O banco cria índice na chave primária automaticamente?

Sim. No PostgreSQL, toda chave primária recebe um índice automaticamente. Em outras chaves, como e-mail ou username, a criação é responsabilidade sua.

Por que não criar índice em todas as colunas?

Porque cada índice ocupa espaço e desacelera inserções. Se a coluna não é alvo de buscas frequentes, o índice só adiciona custo sem benefício.

Índice hash serve para busca por prefixo?

Não. O índice hash só funciona com match exato. Para buscas por prefixo, faixa ou ordenação, o B-tree é a escolha adequada.

Índice composto substitui o B-tree?

Não. São conceitos independentes: composto define quais colunas são indexadas, B-tree define a estrutura de dados usada. Um índice composto padrão utiliza B-tree por baixo.

Índice único e índice parcial podem coexistir?

Sim. Unicidade impede valores duplicados; parcial restringe quais linhas entram no índice. As propriedades se combinam livremente com o tipo de estrutura escolhido.

Índice de banco de dados: 6 tipos que você precisa conhecer

Um índice de banco de dados é uma estrutura de dados extra que acelera buscas na tabela, ao custo de escritas mais lentas e mais espaço em disco. Você escolhe as colunas com base no padrão de acesso da aplicação: o que é buscado com frequência merece índice, o resto não.

O que é um índice de banco de dados

Um índice de banco de dados é uma estrutura de dados subjacente que acelera o acesso às linhas de uma tabela. Quando você cria uma tabela com chave primária, o banco já cria um índice nela automaticamente. No PostgreSQL, o PostgreSQL da The PostgreSQL Global Development Group, isso acontece sempre na chave primária, e você não precisa fazer nada.

SQL armazena dados em linhas e colunas. Numa tabela com id, nome, e-mail e created_at, cada linha fica gravada em sequência. O índice cria uma estrutura adicional, guardada junto com os dados. Ela ocupa espaço extra, mas serve como um atalho para encontrar valores sem ler tudo.

Sem índice, buscar o nome "Fernando" força um full table scan: o banco percorre linha por linha até achar o resultado. É custoso e lento em tabelas grandes. É exatamente esse problema que o índice existe para eliminar.

Como a B-tree acelera a busca por ID

O índice padrão do PostgreSQL é o B-tree, um tipo de árvore balanceada que organiza valores de forma ordenada. Conforme você insere IDs 1, 2, 3, 4, 5, a estrutura se reordena automaticamente para manter a busca eficiente. Em 2026, a documentação oficial do PostgreSQL segue recomendando o B-tree como tipo default para a maioria dos casos.

A busca funciona por comparações. Para achar o ID 7, o banco pergunta: 7 é maior ou menor que 4? Maior, vou para a direita. Maior ou menor que 6? Maior, sigo adiante. Foram três etapas para encontrar o valor, contra sete leituras na tabela sem índice.

O B-tree também é muito bom em buscas por faixa (range). Se você pede todos os IDs entre 1 e 3, eles já estão "juntinhos" na árvore por causa da ordenação. O mesmo vale para created_at: com índice nesse campo, encontrar registros criados entre duas datas é trivial.

O preço do índice: escritas mais lentas e mais espaço

Todo índice tem custo. A estrutura extra ocupa espaço em disco, então a tabela fica necessariamente mais pesada. E cada inserção precisa atualizar o índice, o que torna a criação de novos registros mais lenta.

Essa reordenação do B-tree a cada inserção tem custo computacional. Por isso ninguém cria índice em tudo: se você não executa muitas buscas sobre aquela coluna, o índice só adiciona peso e lentidão de escrita sem devolver nada em troca.

A regra de ouro é simples: o índice é ditado pelo padrão de acesso. Numa rede social, você busca por @username muito mais vezes do que cria usuários novos. Busca frequente e inserção rara é o cenário perfeito para um índice na coluna de username.

Tipos de índice e quando usar cada um

O B-tree é o mais comum, mas não é o único. A documentação de tipos de índice do PostgreSQL descreve as famílias disponíveis, e cada uma serve um padrão de acesso diferente. A tabela abaixo resume as opções mais úteis no dia a dia.

Tipo	Melhor uso	Limitação principal
B-tree	Busca exata e por faixa, ordenação	Escrita e espaço extras
Hash	Match exato, complexidade média O(1)	Não serve para range, ordenação ou prefixo
Composto	Consultas que filtram duas colunas juntas	Só ajuda se a ordem das colunas bate com a query
Parcial (filtrado)	Subset da tabela acessado com frequência	Só indexa linhas que atendem à condição
Full text	Busca dentro de textos completos	Armazenamento pesado, mapeia cada token
Espacial	Geolocalização, como restaurantes num raio de 2 km	Inútil fora de casos com coordenadas

O índice hash funciona como um hash map: a função hash sempre gera a mesma chave para o mesmo valor, e a busca tem complexidade média O(1). A contrapartida é que ele exige match exato. Procurar nomes que começam com "Augus" não funciona com hash.

Esses conceitos se combinam sem conflito. Um índice composto sobre name e e-mail, por padrão, ainda é um B-tree; "composto" diz respeito apenas a quais colunas são indexadas. Da mesma forma, um índice único apenas impede valores duplicados, e um índice parcial só inclui as linhas que passam na condição definida.

Como decidir se vale a pena criar o índice

Decidir exige olhar a aplicação, não a tabela. Pergunte com que frequência cada busca acontece e como ela é feita. O material de referência clássico sobre esse raciocínio é o livro Use The Index, Luke, de Markus Winand, que detalha exatamente como o índice atende padrões de acesso.

Um caminho prático de decisão:

Liste as queries mais executadas pela aplicação.
Verifique se cada uma já é atendida por um índice existente, como o da chave primária.
Para as que não são, escolha o tipo: B-tree para faixa e prefixo, hash para match exato, parcial quando só um subset importa.
Meça antes e depois, observando o impacto tanto na leitura quanto na escrita.

Se o seu caso exige match parcial de texto, o B-tree é o caminho natural. Se exige só igualdade exata, hash pode ser mais rápido. Se o domínio é geográfico, o índice espacial é o único que faz sentido. Índice é sempre criado com base no padrão de acesso e na necessidade da aplicação, nunca por precaução.

Perguntas frequentes sobre índices

O banco cria índice na chave primária automaticamente? Sim. No PostgreSQL, toda chave primária recebe um índice automaticamente. Em outras chaves, como e-mail ou username, a criação é responsabilidade sua.

Por que não criar índice em todas as colunas? Porque cada índice ocupa espaço e desacelera inserções. Se a coluna não é alvo de buscas frequentes, o índice só adiciona custo sem benefício.

Índice hash serve para busca por prefixo? Não. O índice hash só funciona com match exato. Para buscas por prefixo, faixa ou ordenação, o B-tree é a escolha adequada.

Índice composto substitui o B-tree? Não. São conceitos independentes: composto define quais colunas são indexadas, B-tree define a estrutura de dados usada. Um índice composto padrão utiliza B-tree por baixo.

Índice único e índice parcial podem coexistir? Sim. Unicidade impede valores duplicados; parcial restringe quais linhas entram no índice. As propriedades se combinam livremente com o tipo de estrutura escolhido.

Do vídeo para o artigo: transforme suas explicações

Índices resolvem o problema de encontrar informação rápida num banco de dados; o desafio do criador de conteúdo é parecido: fazer quem busca encontrar seu conhecimento. Se você explica conceitos assim em vídeos, como o canal do Gustavo Dev Doido faz com material do Crazystack Typescript e do Bootcamp do Dev Doido, esse conteúdo merece também uma versão escrita que os buscadores consigam indexar.

É exatamente isso que o Skala Blog faz. Você cola a URL de um vídeo do YouTube, a ferramenta transcreve e gera um artigo estruturado, pronto para revisar e publicar.

Source video