Fundamentos do PostgreSQL
PostgreSQL é um banco de dados relacional de código aberto e compatível com padrões que combina um motor SQL rigoroso com um sistema extensível de tipos e índices construído para ser estendido em vez de substituído.
//
Busque em todas as páginas da documentação
PostgreSQL é um banco de dados relacional de código aberto e compatível com padrões que combina um motor SQL rigoroso com um sistema extensível de tipos e índices construído para ser estendido em vez de substituído.
Esta página estabelece a base conceitual para o restante do grupo PostgreSQL Core & SQL: como um cluster, banco de dados, esquema e tabela se relacionam entre si, como uma única consulta é realmente executada internamente e onde as escolhas de design do PostgreSQL diferem de outros sistemas relacionais.
Um servidor PostgreSQL em execução é chamado de cluster, e um único cluster pode hospedar muitos bancos de dados independentes, mesmo que a palavra "cluster" não tenha nada a ver com múltiplas máquinas.
Cada banco de dados é um namespace separado para esquemas, e uma conexão de cliente se anexa a exatamente um banco de dados durante toda a sua sessão.
Dentro de um banco de dados, um esquema agrupa tabelas, views, funções e outros objetos relacionados, da mesma forma que pastas agrupam arquivos.
O PostgreSQL envia um esquema padrão chamado public, mas sistemas de produção normalmente definem seus próprios esquemas para separar aplicações, tenants ou módulos lógicos.
Cada objeto que você cria, de uma tabela a um tipo personalizado, é em si uma linha em uma tabela de catálogo do sistema, que é por que o PostgreSQL pode descrever sua própria estrutura usando SQL comum.
Pense no cluster como um armário de arquivos, cada banco de dados como uma gaveta, cada esquema como uma pasta dentro dessa gaveta, e cada tabela como um fichário rotulado dentro dessa pasta.
O PostgreSQL também implementa o padrão SQL rigorosamente, o que significa que a maioria das sintaxes SELECT, JOIN e de restrição parecerá familiar para qualquer pessoa vinda de outro banco de dados relacional.
Onde o PostgreSQL diverge do padrão, ele geralmente adiciona capacidade em vez de substituí-la, como tipos nativos de array e JSON ao lado de tipos escalares padrão.
Um cluster PostgreSQL é executado como um processo supervisor chamado postmaster, que escuta novas conexões e cria um processo backend dedicado para cada uma delas.
Esse modelo de um processo por conexão significa que cada sessão obtém isolamento total de outras sessões, mas também significa que a contagem de conexões consome diretamente memória e sobrecarga de agendamento de CPU.
Quando um backend recebe uma consulta, o PostgreSQL analisa o texto SQL em uma árvore de análise (parse tree), o reescreve de acordo com quaisquer views ou regras, e o entrega ao planejador (planner).
O planejador é um otimizador baseado em custo que estima a maneira mais barata de satisfazer a consulta usando estatísticas de tabela e coluna coletadas por ANALYZE.
O plano escolhido é entregue ao executor, que puxa linhas através de uma árvore de operadores como scans sequenciais, scans de índice, joins e ordenações.
Por baixo de tudo isso, o PostgreSQL usa controle de concorrência multiversão, ou MVCC, para que leitores nunca bloqueiem escritores e escritores nunca bloqueiem leitores.
O MVCC funciona mantendo múltiplas versões de uma linha e permitindo que cada transação veja um snapshot consistente com base em quando ela começou.
Toda alteração é primeiro registrada no write-ahead log, ou WAL, antes que a página de dados correspondente seja modificada na memória, o que torna a recuperação de falhas possível.
Versões de linha antigas que não são mais visíveis para qualquer transação se tornam tuplas mortas, e o processo autovacuum recupera esse espaço em segundo plano.
cliente -> postmaster (cria fork) -> backend
backend: parse -> rewrite -> plan -> execute
execute: registro WAL -> shared buffers -> (checkpoint) -> disco
Este pipeline, do parse ao WAL até o disco, é por que o PostgreSQL pode garantir durabilidade enquanto ainda agrupa escritas físicas para desempenho.
O design orientado a catálogo do PostgreSQL também é o que o torna extensível sem bifurcar o motor principal, já que extensões como pgvector ou PostGIS simplesmente registram novos tipos, operadores e métodos de acesso a índices nas mesmas tabelas de catálogo que o motor principal usa.
A partir do PostgreSQL 18.4, o projeto segue um ciclo de lançamento de versão principal anual, com a 18 sendo a linha estável atual e a 17 ainda recebendo atualizações de manutenção.
Essa cadência previsível é importante para o planejamento de atualizações, pois cruzar uma versão principal geralmente requer um dump/restore lógico ou uma transição de replicação lógica em vez de uma troca binária in-place.
Um único cluster PostgreSQL escala verticalmente bastante, mas eventualmente as cargas de trabalho precisam espalhar leituras, escritas ou ambas por mais de um nó.
Replicação de streaming, pooling de conexões e extensões especializadas abordam cada parte desse problema de escalonamento, e usar a abordagem errada para a carga de trabalho é um erro comum de arquitetura.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Escalonamento vertical (primário maior) | Mais simples de operar, sem complexidade distribuída | Atinge limites de hardware, ponto único de falha | A maioria das cargas de trabalho antes que o volume de leitura/escrita ultrapasse uma máquina |
| Réplicas de leitura (replicação de streaming) | Descarrega tráfego de leitura, barato de adicionar | Latência de replicação, sem capacidade de escrita adicional | Aplicações com muitas leituras e relatórios |
| Pooling de conexões (PgBouncer) | Reduz a sobrecarga de backend/conexão sem alterações na aplicação | Adiciona um salto, pooling em modo de transação quebra alguns recursos de sessão | Aplicações de alta concorrência com muitas conexões de curta duração |
| PostgreSQL Gerenciado (RDS, Cloud SQL) | Descarrega patching, backup e failover para o provedor | Menos controle sobre extensões e ajuste do kernel | Equipes sem capacidade dedicada de operações de banco de dados |
Nenhuma dessas abordagens substitui as outras, e a maioria dos sistemas de produção as combina em camadas à medida que a carga cresce.
shared_buffers, exigem uma reinicialização completa.Um cluster é o processo do servidor em execução e seu diretório de dados, enquanto um banco de dados é um namespace dentro desse cluster que comumente compartilha o cluster com vários bancos de dados irmãos.
Significa que uma consulta de relatório de longa execução nunca bloqueia uma escrita concorrente, uma escrita nunca precisa esperar que os leitores terminem, e cada transação simplesmente vê um snapshot consistente dos dados em vez de alterações parciais de outros.
Cada alteração é registrada de forma durável no WAL antes que a página na memória seja considerada confirmada, o que permite ao PostgreSQL reproduzir o WAL desde o último checkpoint e reconstruir qualquer estado perdido na memória após uma falha.
Um reload relê postgresql.conf para configurações que podem mudar ao vivo, enquanto um restart recicla o postmaster e todos os backends, o que é necessário para configurações como shared_buffers que são fixadas na inicialização.
Não para começar, mas entender que o planner reordena e reescreve seu SQL explica a maioria das surpresas de "por que isso está lento" mais tarde.
Porque tipos, operadores e métodos de acesso a índices são apenas linhas em catálogos do sistema, extensões podem registrar novos sem modificar o código-fonte do motor principal.
Tuplas mortas se acumulam, tabelas incham e, no pior caso, o cluster se aproxima do "transaction ID wraparound", o que força o PostgreSQL a um modo de limpeza protetor e disruptivo.
Sim; 18 é a versão principal estável atual, e a 17 permanece na linha de manutenção suportada para equipes que ainda não estão prontas para atualizar.
Uma extensão pode adicionar novos tipos de dados, operadores e métodos de acesso a índices que participam do planner e executor exatamente como os embutidos, não apenas adicionar funções chamáveis.
Sim, usando bancos de dados separados ou esquemas separados, embora cada limite de isolamento tenha implicações diferentes para o escopo de backup e contabilidade de conexões.
Cada conexão é um processo backend completo consumindo memória e competindo pelo agendamento da CPU, então centenas de conexões ociosas são baratas, mas centenas de conexões ativas não são.
Porque seu modelo de durabilidade, escritas WAL-antes-da-página-de-dados mais replay em caso de falha, tem sido estável e testado em batalha por décadas, com novos recursos adicionados em torno desse núcleo em vez de substituí-lo.
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, e PostGIS 3.5+.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026