Como Adicionar um Banco de Dados ao Seu App (Sem Perder Dados Depois)

Para adicionar um banco de dados ao seu app, escolha um banco relacional gerenciado (o Postgres é o padrão mais usado), guarde a string de conexão em um segredo do lado do servidor, crie uma tabela para cada tipo de coisa que o app armazena e faça com que o seu backend — nunca o navegador — leia e escreva nele. Se você cria com um construtor de apps com IA, normalmente basta dizer “salve isso em um banco de dados”, e o agente configura as tabelas e o código. O seu papel é descrever os dados com clareza e conferir se eles realmente são gravados.

Este guia explica quando você precisa de um banco de dados, as principais opções, como descrever os seus dados e os erros que causam perda ou vazamento de dados.

Quando o seu app precisa de um banco de dados

Você precisa de um banco de dados quando o app tem que lembrar de algo depois que a página é fechada, ou compartilhar dados entre pessoas. Sinais típicos:

• Visitantes enviam algo: um formulário, um cadastro, um agendamento, um pedido
• Usuários têm contas com conteúdo salvo próprio
• Um administrador precisa ver ou editar o que outros criaram
• Você quer relatórios ou contagens ao longo do tempo

Você não precisa de um banco de dados para um site estático em que todos veem o mesmo conteúdo, como um portfólio ou uma landing page simples. Se você não sabe exatamente o que é um banco de dados, leia primeiro o que é um banco de dados.

Suas opções

Para a maioria dos apps web pequenos e médios, um banco relacional como o Postgres é a escolha padrão certa. Ele é bom com relacionamentos (um cliente tem vários pedidos), mantém os dados consistentes e permite responder perguntas depois com SQL. Veja o que é o Postgres para uma explicação simples.

Descreva os seus dados antes de criar

A coisa mais útil que você pode fazer é anotar as coisas que o seu app armazena e como elas se conectam. Você não precisa de jargão de banco de dados. Para um app de agendamentos:

• Clientes: nome, e-mail, telefone
• Serviços: nome, duração, preço
• Agendamentos: qual cliente, qual serviço, horário de início, status (pendente, confirmado, cancelado)

São três tabelas. “Qual cliente” e “qual serviço” viram ligações (chaves estrangeiras) entre elas. Acertar isso logo no início importa muito mais do que qualquer escolha de tecnologia, porque mudar a estrutura de dados que já têm registros reais é mais difícil do que mudar o layout de uma página.

Algumas regras práticas:

• Uma tabela para cada tipo de coisa. Não junte pedidos em uma coluna de texto dentro do cliente.
• Dê a cada registro um ID e uma data de criação. Você vai precisar dos dois depois.
• Use tipos adequados. Datas como datas, valores monetários como centavos inteiros ou tipo decimal, e não como texto.
• Marque os campos obrigatórios como obrigatórios. Deixe o banco rejeitar dados ruins, e não apenas o formulário.

Prompts de exemplo

Comece com uma funcionalidade por vez, em vez de despejar um esquema inteiro:

Adicione um banco de dados a este app. Crie uma tabela de agendamentos com nome do cliente, e-mail, serviço, horário de início e status (pendente, confirmado, cancelado; o padrão é pendente). Salve os envios do formulário de agendamento nela, mostre uma mensagem de sucesso e adicione uma página de administração que liste os agendamentos do mais recente para o mais antigo.

Depois, amplie:

Adicione uma tabela de serviços (nome, duração em minutos, preço em centavos). Troque o campo de serviço de texto livre nos agendamentos por um vínculo com a tabela de serviços, e migre os agendamentos existentes sem apagar nenhum.

E depois, reforce:

Garanta que todas as leituras e gravações no banco aconteçam no servidor. O navegador nunca deve receber a string de conexão com o banco. Valide o e-mail e o horário de início no servidor antes de inserir.

Passo a passo

1. Liste os seus dados como acima: coisas, campos e ligações entre elas.
2. Crie o banco de dados. Em um construtor com IA, peça no chat. Em outros lugares, crie uma instância Postgres gerenciada e copie a string de conexão.
3. Guarde a string de conexão como segredo (uma variável de ambiente no servidor), nunca no código. Veja variáveis de ambiente e segredos.
4. Crie as tabelas. Use migrations — scripts versionados que alteram o esquema — para que as mudanças sejam repetíveis e reversíveis.
5. Crie as rotas do servidor que criam, leem, atualizam e apagam registros (CRUD). O navegador chama essas rotas; ele nunca fala diretamente com o banco.
6. Conecte a interface a essas rotas: formulários que salvam, listas que carregam, estados vazios quando ainda não há nada.
7. Teste a persistência. Envie algo, recarregue a página, abra em outro navegador. Se o dado não estiver lá, ele não foi salvo no banco.
8. Confira o acesso. Entre com um segundo usuário e confirme que você não consegue ver nem editar os dados do primeiro.
9. Publique e teste de novo na URL no ar, já que o app publicado pode usar uma conexão diferente da do preview.

Erros comuns

• Salvar no navegador e achar que está salvo. O localStorage parece funcionar até alguém abrir o app em outro dispositivo. Sempre teste em um segundo navegador.
• Colocar a string de conexão no código do frontend. Qualquer pessoa pode ler o código do frontend. Isso dá a ela o seu banco inteiro.
• Não verificar acesso. “Mostrar meus pedidos” precisa filtrar pelo usuário logado no servidor, e não na interface. É a falha de segurança mais comum em apps criados com IA; nossa lista de verificação de segurança cobre isso.
• Alterações destrutivas no esquema. Pedir para “renomear a tabela” ou “mudar a estrutura” pode apagar e recriar a tabela. Quando já existem dados reais, diga “migre os registros existentes, não apague nada”.
• Guardar arquivos no banco de dados. Imagens e PDFs pertencem ao armazenamento de arquivos, com apenas a URL ou a chave guardada em uma tabela. Veja como adicionar upload de arquivos.
• Não ter backups. Saiba como a sua plataforma faz backup dos dados e como restaurá-los antes de ter clientes.

Checklist

• Cada tipo de coisa tem a sua própria tabela, com ID e data de criação
• Campos obrigatórios e tipos são garantidos pelo banco
• A string de conexão fica apenas em segredos do servidor
• Todas as leituras e gravações passam por rotas do servidor
• Cada usuário só consegue ler e alterar os próprios registros
• Os dados sobrevivem a um recarregamento e aparecem em outro navegador
• Alterações de esquema usam migrations e mantêm os registros existentes
• Você sabe como funcionam os backups e a restauração
• O app no ar foi testado depois da publicação

Como adicionar um banco de dados no Mythex

No Mythex, cada projeto pode ter o próprio banco Postgres dedicado, tanto no Free quanto no Pro. Normalmente você não precisa clicar em um botão separado de “conectar”: peça no chat (“salve os e-mails da lista de espera em um banco de dados”) ou digite /database, e os dados de conexão são injetados no workspace e no seu app publicado. As configurações do projeto mostram se o banco está ativo.

O banco entra em modo de espera após 5 minutos ociosos e acorda na próxima requisição. O uso publicado é cobrado pelo tempo em que o banco ficou realmente ativo, a partir do mesmo saldo de créditos que você usa para criar. Se você adicionar um banco depois de já ter publicado, publique de novo para que o app no ar use a nova conexão.

Veja Banco de dados e a receita Crie um app CRUD na documentação. Para o lado de login dos dados por usuário, leia como adicionar login ao seu app.

Perguntas