O que é PostgreSQL e para que serve

Quase todo sistema acaba precisando guardar dados que se relacionam: usuários, pedidos, produtos, pagamentos. Em vez de espalhar isso em arquivos, você usa um banco de dados que garante que a informação continue correta mesmo quando várias pessoas escrevem ao mesmo tempo. O PostgreSQL é um dos bancos mais usados para esse trabalho.

Ele é popular entre desenvolvedores porque faz bem o básico (tabelas, SQL, transações) e acompanha o projeto quando ele cresce, com JSON, dados geográficos e extensões.

O que é PostgreSQL?#

PostgreSQL, também chamado de Postgres, é um sistema de banco de dados relacional (SGBD) open source. Ele começou em 1986 como o projeto POSTGRES, na Universidade da Califórnia, em Berkeley, e tem décadas de desenvolvimento ativo. A licença é a PostgreSQL License, liberal e parecida com BSD e MIT.

Relacional quer dizer que os dados ficam em tabelas, com linhas e colunas, e que as tabelas se ligam por chaves. Você descreve o que quer em SQL, a linguagem padrão de consulta, e o servidor decide como buscar.

Como o PostgreSQL funciona?#

O PostgreSQL roda como um servidor. Sua aplicação abre uma conexão (porta padrão 5432), envia comandos SQL e recebe linhas de volta. Três ideias explicam a maior parte do comportamento.

Esquema. Cada tabela tem colunas com tipos definidos, e o banco recusa dados que não respeitam as regras. Restrições como NOT NULL, UNIQUE, chave primária e chave estrangeira mantêm a integridade: não existe um pedido apontando para um usuário que não existe.

Transações ACID. Uma transação agrupa vários comandos: ou todos acontecem, ou nenhum acontece. ACID significa atomicidade, consistência, isolamento e durabilidade. Se você debita uma conta e credita outra, ou os dois passos valem, ou nenhum. O PostgreSQL é compatível com ACID desde 2001.

MVCC e WAL. Com o controle de concorrência multiversão (MVCC), cada comando enxerga uma versão consistente dos dados, então quem lê não bloqueia quem escreve, e vice-versa. Já o log de escrita antecipada (WAL) grava cada alteração em um log antes de aplicá-la às tabelas. É ele que permite recuperar o banco depois de uma queda e alimenta a replicação.

Exemplo: duas tabelas e uma consulta#

CREATE TABLE users (
  id    bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email text NOT NULL UNIQUE
);

CREATE TABLE orders (
  id      bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  user_id bigint NOT NULL REFERENCES users (id),
  total   numeric(10, 2) NOT NULL
);

INSERT INTO users (email) VALUES ('ana@example.com');
INSERT INTO orders (user_id, total) VALUES (1, 49.90);

SELECT u.email, sum(o.total) AS gasto
FROM users u
JOIN orders o ON o.user_id = u.id
GROUP BY u.email;

O REFERENCES impede um pedido sem usuário, e o JOIN junta as duas tabelas na consulta.

Exemplo: usar no Node.js#

Com o driver pg, o pool lê as variáveis PGHOST, PGUSER, PGPASSWORD, PGPORT e PGDATABASE, as mesmas do psql. Nunca coloque a senha no código. Se o servidor exige TLS com certificado de cliente, leia os arquivos de certificado e passe o conteúdo na opção ssl.

import { readFileSync } from "node:fs";
import pg from "pg";

// host, usuário, senha, porta e banco vêm das variáveis PG* do ambiente
const pool = new pg.Pool({
  ssl: {
    ca: readFileSync("ca-certificate.crt", "utf8"), // CA em que o cliente confia
    cert: readFileSync("certificate.pem", "utf8"), // certificado do cliente
    key: readFileSync("private-key.key", "utf8"), // chave privada do cliente
  },
});

const email = "ana@example.com";
const { rows } = await pool.query(
  "SELECT id, email FROM users WHERE email = $1",
  [email],
);
console.log(rows);

await pool.end();

O $1 é um parâmetro: o valor viaja separado do texto SQL, o que evita SQL injection. Nunca monte a consulta concatenando strings.

Para que serve o PostgreSQL?#

• Aplicações web e APIs com usuários, pedidos, permissões e relatórios.
• Sistemas financeiros e de estoque, em que uma transação pela metade é inaceitável.
• Bots que guardam configurações por servidor, economia, histórico ou moderação, sobretudo quando os dados se relacionam.
• Dados geográficos, com a extensão PostGIS.
• Análises com agregações e consultas complexas, sem sair do SQL.

O que o PostgreSQL tem de diferente?#

JSONB. Os tipos json e jsonb guardam documentos dentro de uma coluna. A documentação recomenda jsonb para a maioria dos casos: ele é mais rápido de processar e aceita índices GIN e o operador de contenção @>.

CREATE TABLE eventos (id bigserial PRIMARY KEY, dados jsonb NOT NULL);
CREATE INDEX eventos_dados_idx ON eventos USING GIN (dados);

SELECT id, dados ->> 'tipo' AS tipo
FROM eventos
WHERE dados @> '{"origem": "bot"}';

Índices variados. Além do B-tree padrão, existem GiST, GIN e BRIN, cada um para um tipo de dado e de consulta.

Extensões. Você adiciona funções, tipos e índices sem trocar de banco. PostGIS, para dados geográficos, é o exemplo mais conhecido.

Tipos ricos. Arrays, intervalos, UUID, XML e tipos que você mesmo define.

Replicação e recuperação. Replicação síncrona, assíncrona e lógica, e recuperação até um ponto no tempo, a partir do WAL.

Quando não usar PostgreSQL?#

• Cache e contadores muito quentes: um armazenamento em memória como o Redis responde mais rápido nesse papel.
• Arquivos grandes: imagens e vídeos ficam melhor em armazenamento de objetos. Guarde no banco só o caminho ou a URL do arquivo.
• Projetos minúsculos e locais: se o app roda numa máquina só e o volume é pequeno, um arquivo SQLite pode bastar.
• Dados sem estrutura fixa e sem relações: um banco de documentos como o MongoDB pode ser mais direto, embora o JSONB cubra muita coisa.

Para decidir entre as opções, leia qual banco de dados escolher. Se a dúvida é entre os dois relacionais mais comuns, veja PostgreSQL vs MySQL e o que é MySQL.

Como o PostgreSQL é versionado?#

Sai uma versão principal por ano, e cada uma recebe correções de bug e de segurança por 5 anos. A tabela oficial de versões mostra quais ainda têm suporte. Atualizações menores (de uma x.5 para a x.6, por exemplo) normalmente só pedem reiniciar o servidor com os novos binários (leia as notas da versão antes). Já a troca de versão principal exige pg_upgrade ou dump e restauração, então planeje isso antes de uma versão perder suporte.

Qualquer que seja a versão, mantenha cópias do seu banco. O guia de como fazer backup de um banco de dados mostra o passo a passo.

Como fazer isso na Square Cloud#

O que este artigo mostrou no núcleo do PostgreSQL (esquema com chaves estrangeiras, transações, JSONB com índice GIN e consultas parametrizadas) funciona na hospedagem de PostgreSQL da Square Cloud, disponível a partir do plano Standard; o Hobby não inclui bancos. É o PostgreSQL nativo, sem extensões: PostGIS, pgvector e afins não estão disponíveis, então confira isso antes se o seu projeto depende de uma delas. Você cria o banco no painel, sempre numa versão recente, com no mínimo 1024 MB da RAM do plano, e ele fica pronto em segundos no mesmo datacenter das suas aplicações, com latência média de cerca de 1 ms.

O exemplo em Node.js já segue o formato de conexão exigido. O TLS é obrigatório: baixe no painel os arquivos ca-certificate.crt, certificate.pem e private-key.key e leia-os na opção ssl, porque o cliente precisa confiar na CA e apresentar o próprio certificado. Guarde os dados da URL de conexão (host, porta, usuário, senha e banco) nas variáveis PG* da aplicação e reinicie para elas valerem. Para os contadores muito quentes que o PostgreSQL não deve carregar, um Redis pode rodar ao lado, no mesmo plano.

Você tira snapshots manuais quando quiser, por exemplo antes de uma mudança de esquema, e todo plano com bancos faz também um snapshot automático diário, guardado por 7 dias. O snapshot restaura no mesmo banco, em outro PostgreSQL ou num banco novo, ou sai como .zip.

Veja detalhes e planos em Hospedagem de PostgreSQL.