O que é Postgres? O banco de dados por trás de muitos apps, explicado
Postgres (oficialmente PostgreSQL) é um banco de dados relacional gratuito e de código aberto: um programa que guarda os dados de um app em tabelas de linhas e colunas, conecta essas tabelas entre si e responde a perguntas sobre elas em uma linguagem chamada SQL. É conhecido por ser confiável, rigoroso em manter os dados corretos e flexível o bastante para lidar com desde uma lista de inscritos até os registros de uma grande empresa. Muitos apps web, e muitos dos serviços que os hospedam, são construídos sobre ele.
Por que isso importa quando você cria apps com IA
Quando uma ferramenta de criação de apps com IA adiciona “um banco de dados” ao seu projeto, há boas chances de ser Postgres. Você não precisa escrever SQL para usá-lo, mas um pouco de entendimento ajuda muito:
- Você pode descrever os dados na forma que o banco precisa. “Clientes têm muitos pedidos; cada pedido tem muitos itens” se traduz diretamente em tabelas.
- Você pode pedir as proteções certas. O Postgres consegue recusar dados ruins por conta própria — um e-mail duplicado, um pedido para um cliente que não existe — se a IA configurar as regras.
- Você consegue ler o que a IA fez. Nomes de tabelas, colunas e relacionamentos são fáceis de conferir em um visualizador de tabelas, mesmo que você nunca toque no código.
Uma analogia do dia a dia: um cartório muito rigoroso
Imagine um escritório de arquivos com um armário para cada tipo de coisa — um para clientes, um para pedidos, um para produtos. Cada ficha em uma gaveta tem os mesmos campos impressos para preencher. Cada ficha tem um número único, e a ficha de um pedido não repete os dados do cliente; apenas diz “cliente nº 214”, apontando para a gaveta de clientes.
O funcionário é rigoroso. Ele não arquiva um pedido que aponta para um cliente inexistente. Não aceita uma ficha com um campo obrigatório em branco. E, se você pedir para transferir dinheiro de uma ficha de conta para outra, ele faz as duas partes ou nenhuma — nunca só uma.
Esse funcionário é o Postgres. As gavetas são as tabelas, os campos impressos são as colunas, cada ficha é uma linha, e o vínculo “cliente nº 214” é uma chave estrangeira (foreign key).
O que o Postgres faz bem
| Recurso | O que significa em palavras simples |
|---|---|
| Tabelas e relacionamentos | Os dados ficam em tabelas que apontam umas para as outras, então nada é copiado em cinco lugares |
| SQL | Uma linguagem padrão para fazer perguntas: “todos os pedidos não pagos do mês passado, do mais recente para o mais antigo” |
| Transações (ACID) | Um grupo de alterações acontece por completo ou não acontece, mesmo que o servidor caia no meio do caminho |
| Restrições (constraints) | Regras que o próprio banco aplica: campos obrigatórios, e-mails únicos, vínculos válidos entre tabelas |
| Índices | Atalhos de busca para que as consultas continuem rápidas à medida que as tabelas crescem |
| JSONB | Guarda dados flexíveis, no estilo de documento, em uma coluna quando uma estrutura fixa não serve |
| Busca em texto completo | Busca palavras em campos de texto sem um serviço de busca separado, em casos simples |
| Extensões | Complementos como o PostGIS para mapas e localização, ou o pgvector para guardar embeddings de IA |
| Segurança em nível de linha | Regras dentro do banco sobre quais linhas um determinado usuário pode ver |
O Postgres começou como um projeto de pesquisa na Universidade da Califórnia, em Berkeley, nos anos 1980, e vem sendo desenvolvido de forma aberta por uma comunidade global desde os anos 1990. Essa longa história explica por que ele costuma ser a escolha padrão: é bem documentado, amplamente suportado, e todos os grandes provedores de nuvem oferecem uma versão gerenciada.
Um exemplo prático: transformar uma planilha em tabelas
Suponha que você tenha um pequeno negócio de buffet e registre tudo em uma única planilha: cada linha é um evento, com o nome, o telefone e o e-mail do cliente, a data, os itens do cardápio e o preço.
Os problemas aparecem rápido. O mesmo cliente aparece em seis linhas com dois telefones diferentes. Os itens do cardápio são digitados em uma célula só como “canapés x40, salada x2”, então você não consegue somar quantos canapés fez no mês.
No Postgres, as mesmas informações viram quatro tabelas:
| Tabela | Colunas | Observações |
|---|---|---|
| clientes | id, nome, telefone, email | O e-mail precisa ser único |
| eventos | id, cliente_id, data, local, status | cliente_id precisa corresponder a um cliente real |
| itens_cardapio | id, nome, preco_unitario | Uma linha por prato |
| itens_evento | evento_id, item_cardapio_id, quantidade | Liga eventos a pratos, com uma quantidade |
Agora o telefone de um cliente fica em um só lugar. “Quantos canapés fizemos em março?” é uma única consulta SQL. E, ao registrar um novo evento com os seus itens, uma transação garante que você nunca fique com um evento que tenha só metade dos itens salvos.
Esse é o passo que muita gente pula quando pede a uma IA para “fazer um app a partir da minha planilha”. O guia para transformar uma planilha em app vai além.
Termos principais
- Tabela, linha, coluna: um tipo de coisa, uma instância dela, uma informação sobre ela.
- Chave primária: o ID único de cada linha, normalmente
id. - Chave estrangeira: uma coluna que aponta para uma linha em outra tabela, como
cliente_id. - Schema: o desenho de todas as suas tabelas e colunas.
- Migração: uma alteração salva e repetível no schema, como “adicionar uma coluna
localem eventos”. - Consulta (query): uma pergunta ou instrução escrita em SQL.
- String de conexão: o endereço e a senha que o seu backend usa para chegar ao banco. É um segredo — veja variáveis de ambiente e segredos.
- Postgres gerenciado: um serviço que executa, faz backup e atualiza o Postgres para você.
Para as operações do dia a dia que todo app faz sobre essas tabelas — criar, ler, atualizar, excluir —, veja o que significa CRUD.
Erros comuns e ideias equivocadas
- Uma tabela gigante. Copiar a planilha coluna por coluna leva aos mesmos problemas de duplicação. Separe em tabelas próprias o que se repete.
- Guardar listas em um único campo de texto. “canapés x40, salada x2” em uma só coluna não pode ser contado nem pesquisado direito. Use uma tabela de ligação.
- Nenhuma restrição. Sem “o e-mail precisa ser único” ou “todo evento precisa de um cliente”, dados ruins entram sem alarde e aparecem meses depois.
- Alterar o banco à mão em produção. Peça alterações de schema como migrações, para que a mudança fique registrada e possa ser repetida.
- Deixar o navegador falar diretamente com o banco. O frontend deve passar pelo seu backend, que verifica as permissões. A senha do banco nunca pertence ao código da página.
- “O Postgres é só para grandes empresas.” Ele roda igualmente bem para uma lista de espera com 50 linhas, e você não precisará sair dele conforme cresce.
- Achar que um banco de dados é um backup. Ele guarda dados; não o protege automaticamente de exclusões. Verifique quais backups a sua hospedagem oferece.
O que pedir à sua ferramenta de IA
- “Guarde [coisas] em um banco de dados. Tabelas: … com estes campos: … Vincule cada [pedido] a um [cliente].”
- “Torne o e-mail único em clientes. Torne estes campos obrigatórios. Não permita um pedido sem cliente.”
- “Use migrações para toda alteração de schema.”
- “Adicione índices para as buscas que mais fazemos: pedidos por cliente e por data.”
- “Todo acesso ao banco passa pelo servidor. Guarde a string de conexão em variáveis de ambiente.”
Se você ainda não conhece a ideia de banco de dados, comece por o que é um banco de dados e depois volte aqui. Um app full-stack mostra onde o banco fica ao lado do frontend e do backend.
Postgres no Mythex
O Mythex dá a cada projeto que precisa dele um banco Postgres dedicado. Você não precisa configurá-lo: peça no chat (“salve os e-mails da lista de espera em um banco de dados”) ou use o comando /database, e o Mythex o anexa, injeta os dados de conexão no seu app e pode criar as tabelas para você. O banco de um app publicado entra em repouso após cinco minutos ociosos e acorda na próxima requisição, e você paga apenas pelo tempo em que ele ficou realmente ativo, a partir do mesmo saldo de créditos usado para criar. Os detalhes estão na documentação do banco de dados, e os modelos de painel são um bom lugar para ver apps que usam dados.
Perguntas
Postgres é o mesmo que PostgreSQL?
Sim. PostgreSQL é o nome oficial e Postgres é o apelido comum; os dois se referem ao mesmo banco de dados relacional de código aberto.
O Postgres é gratuito?
Sim. O PostgreSQL é de código aberto sob a licença permissiva PostgreSQL License, então você pode usá-lo de graça, inclusive em produtos comerciais. Você paga apenas pelos servidores ou pelo serviço gerenciado que o executa.
Qual é a diferença entre Postgres e MySQL?
Ambos são bancos SQL relacionais e gratuitos, e os dois servem bem para a maioria dos apps. O Postgres é conhecido pela integridade rigorosa dos dados, pelos tipos de dados ricos, como JSONB e arrays, e por um grande ecossistema de extensões; o MySQL é conhecido pela simplicidade e por uma longa história em hospedagem web.
O Postgres serve para um app pequeno?
Sim. Funciona bem para uma lista de espera com uma única tabela e também para grandes sistemas de produção, então você não precisará trocar de banco conforme o app cresce. Serviços gerenciados facilitam rodá-lo sem um administrador de banco de dados.