Questão de Banco de Dados — PostgreSQL — FCC 2026

PostgreSQL: arquitetura baseada em processos e NoSQL

Gabarito: letra D. O PostgreSQL adota uma arquitetura baseada em processos (modelo multi-process), em que cada conexão de cliente é atendida por um processo separado, e o sistema operacional distribui esses processos entre as CPUs disponíveis. As demais alternativas distorcem características do NoSQL, do próprio PostgreSQL e do SQL Server.

O PostgreSQL é um SGBD objeto-relacional de código aberto, conhecido por sua robustez e conformidade com o padrão SQL. Uma de suas características arquiteturais mais marcantes é o modelo baseado em processos: ao contrário de SGBDs que usam threads (como o SQL Server), o PostgreSQL cria um processo dedicado para cada conexão de cliente. Esse processo é chamado de backend e é responsável por executar as consultas daquela conexão específica. O sistema operacional, por sua vez, faz o escalonamento desses processos entre os núcleos da CPU, aproveitando o multiprocessamento. Essa arquitetura oferece isolamento entre conexões — se um processo falhar, os demais não são afetados — e é uma das razões da estabilidade do PostgreSQL.

Para entender a alternativa correta, é preciso distinguir os dois modelos de concorrência usados pelos SGBDs:

No modelo do PostgreSQL, quando uma aplicação cliente usa threads, cada thread que abre uma conexão com o banco será atendida por um processo backend distinto. Isso é exatamente o que a alternativa D afirma: "as aplicações cliente podem usar threads, cada uma das quais se conecta a um processo de banco de dados separado".

Já os bancos NoSQL, como o orientado a documentos e o Key/Value, têm características próprias que as alternativas A e B distorcem. O modelo orientado a documentos armazena dados em documentos (JSON, BSON, XML), não em tabelas com índices compostos fixos. O modelo Key/Value é simples e rápido, mas não foi projetado para garantir atomicidade e integridade referencial entre múltiplas entidades — essas garantias são típicas de bancos relacionais. A alternativa C também erra ao afirmar que o PostgreSQL armazena tabelas em um único arquivo contínuo e que o aumento do block size duplica os limites de tamanho da tabela e do número de colunas. Na verdade, o PostgreSQL armazena cada tabela em múltiplos arquivos (segmentos de 1GB) e o block size padrão é 8KB, podendo ser ajustado na compilação, mas não duplica limites dessa forma. A alternativa E, por fim, atribui ao SQL Server características que não possui: armazenamento nativo em BSON e otimizador orientado a grafos.

A pegadinha central desta questão é a banca misturar características reais de cada tecnologia com invenções plausíveis. O candidato que conhece superficialmente o PostgreSQL pode ser atraído pela alternativa C, que menciona números específicos (32TB, 32MB), mas que são incorretos. A alternativa D, por outro lado, descreve com precisão a arquitetura de processos do PostgreSQL, um detalhe técnico que exige estudo aprofundado.

Alternativa A — ❌ Incorreta

O modelo NoSQL orientado a documentos não utiliza "estrutura interna baseada em tabelas com índices compostos fixos". Pelo contrário, o modelo orientado a documentos armazena dados em documentos (JSON, BSON, XML), que são agrupados em coleções. Os documentos são semelhantes entre si, mas não precisam ter o mesmo esquema — cada documento pode ter campos diferentes. Não há tabelas com índices compostos fixos; a flexibilidade de esquema é uma das principais características desse modelo.

Alternativa B — ❌ Incorreta

O modelo Key/Value é um dos mais simples do NoSQL, armazenando pares chave-valor. Ele é empregado em cenários que exigem alta performance e escalabilidade, como caches e sessões de usuário, mas não foi projetado para garantir "atomicidade e integridade referencial entre múltiplas entidades". Essas garantias são típicas de bancos relacionais (ACID). A maioria dos bancos NoSQL, incluindo os Key/Value, sacrifica a consistência forte em favor de disponibilidade e tolerância a partição (Teorema CAP), oferecendo consistência eventual.

Alternativa C — ❌ Incorreta

A alternativa C contém vários erros sobre o PostgreSQL:

• As tabelas não são armazenadas em um "único arquivo contínuo". O PostgreSQL armazena cada tabela em múltiplos arquivos de 1GB (segmentos), que são gerenciados pelo tablespace.

• O block size padrão é 8KB, não 32MB. Ele pode ser ajustado na compilação (até 32KB em versões recentes), mas não "duplica os limites de tamanho da tabela e do número de colunas".

• O limite de tamanho de tabela no PostgreSQL é de 32TB, mas isso não está relacionado ao block size.

• Índices não podem ser criados em colunas de "qualquer comprimento" — há limites práticos, como o tamanho máximo de uma entrada de índice (cerca de 2704 bytes).

Alternativa D — ✅ Correta ⟵ GABARITO

Esta alternativa descreve corretamente a arquitetura do PostgreSQL. O PostgreSQL utiliza um modelo baseado em processos: cada conexão de cliente é atendida por um processo separado (o backend). O sistema operacional distribui esses processos entre as CPUs disponíveis, aproveitando o multiprocessamento. As aplicações cliente podem usar threads, e cada thread que abre uma conexão será atendida por um processo backend distinto. Essa arquitetura oferece isolamento entre conexões e é uma característica fundamental do PostgreSQL.

Alternativa E — ❌ Incorreta

O SQL Server não possui armazenamento nativo em formato BSON. BSON é um formato usado pelo MongoDB (NoSQL orientado a documentos). O SQL Server armazena dados em páginas e extensões, com suporte a tipos como JSON (a partir da versão 2016), mas não BSON. Além disso, o SQL Server não possui um "otimizador de consultas especificamente orientado a grafos" — ele tem suporte a grafos (a partir da versão 2017), mas o otimizador é o mesmo para consultas relacionais e de grafo, não um otimizador separado.

Gabarito: letra D