Quando seu app criado com IA realmente precisa de um banco de dados (e quando não precisa)

O que um banco de dados realmente faz?

O trabalho de um banco de dados é garantir que duas pessoas não sobrescrevam ou destruam acidentalmente o trabalho uma da outra ao usar o mesmo app — velocidade, estrutura e buscas complexas são apenas efeitos colaterais de resolver esse único problema.

Você construiu seu app com IA. Ele funciona. Salva dados em arquivos ou uma planilha. Tudo parece bem.

Aí uma de duas coisas acontece:

Seu app fica mais lento cada vez que alguém o usa.
Dois usuários tentam usá-lo ao mesmo tempo e algo quebra.

Nenhuma dessas falhas é óbvia até que seja tarde demais. Ambas são problemas de banco de dados disfarçados.

Se você ainda está usando arquivos ou planilhas, provavelmente ainda não precisa de um banco de dados. E tudo bem. Mas você deveria conhecer os sinais de alerta de que está prestes a precisar de um.

Quando está tudo bem usar apenas arquivos em vez de um banco de dados?

Arquivos funcionam bem contanto que você seja a única pessoa usando o app e as mudanças sejam raras — esse é o teste todo.

O site de portfólio de um freelancer? Arquivos são perfeitos. Um controle pessoal de despesas? Arquivos estão ótimos. Um projeto hobby com um único usuário? Não complique.

Sinais reais de que os arquivos estão funcionando:

Apenas uma pessoa usa o app por vez (ou os usuários estão offline enquanto outros trabalham).
Você raramente atualiza os dados (uma vez por dia, uma vez por semana, uma vez por mês).
Perder os últimos 30 segundos de trabalho é aceitável (seu builder pode simplesmente tentar de novo).
O arquivo de dados é pequeno o suficiente para enviar por e-mail (menos de 10 MB).

Se os quatro forem verdade, continue com arquivos. Sério. A simplicidade é uma vantagem, não uma limitação.

Por que meu app criado com IA está ficando mais lento?

Seu app fica mais lento porque o arquivo em que ele salva continua crescendo, e seu builder está carregando o arquivo inteiro na memória toda vez que precisa mudar qualquer coisa — um custo quase imperceptível no início e que se torna dolorido conforme o arquivo cresce.

Você percebe isso como uma sensação. Seu app parece mais lento do que antes. Clicar em um botão leva um segundo a mais. A busca fica visivelmente mais lenta. Você não mudou o código — por que está mais lento? Aqui está o padrão:

O app carrega o arquivo de dados completo (100 linhas, rápido).
Um usuário adiciona um registro (agora 101 linhas).
O app relê o arquivo inteiro para conferir (ainda rápido).
Depois de 2.000 registros, ler o arquivo leva 2 segundos.
Depois de 10.000 registros, leva 20 segundos.

Não é exponencial, mas fica perceptível por volta de 5.000 registros e se torna doloroso por volta de 20.000.

Primeiro conserto (antes de adicionar um banco de dados): peça ao seu builder para carregar dados sob demanda. Carregue apenas os registros que você está exibindo, ou apenas as colunas que você está mostrando. Muitos apps conseguem continuar com arquivos sendo mais inteligentes sobre o que carregam.

Quando migrar para um banco de dados: você tem mais de 50.000 registros de dados, ou a lentidão persiste mesmo depois de otimizar os carregamentos.

Por que meu app perdeu dados quando duas pessoas o usaram ao mesmo tempo?

Isso acontece porque duas pessoas podem editar o mesmo arquivo ao mesmo tempo e o app não tem como saber — quem salva por último vence, e as mudanças da primeira pessoa desaparecem silenciosamente. Isso se chama “escrita conflitante”, e é um bug clássico de perda de dados.

Ambas as pessoas veem suas próprias mudanças na tela. As duas clicam em “salvar”. Você vai saber que isso está acontecendo se:

Usuários relatam dados sumidos de vez em quando (especialmente se várias pessoas estão no app ao mesmo tempo).
Usuários relatam ver mudanças de outras pessoas sendo “desfeitas” sem explicação.
Dois usuários editam o mesmo registro e as edições de uma pessoa somem.
Você recebe mensagens do tipo “eu juro que adicionei isso ontem e agora sumiu”.

A culpa não é do app. É uma limitação de como arquivos funcionam. Não existe uma boa forma de lidar com isso sem um banco de dados.

Quando migrar para um banco de dados: assim que duas pessoas passarem a usar o app ao mesmo tempo, mesmo que ainda não tenha falhado.

Por que meu app não consegue lidar com buscas complexas usando arquivos?

Porque, com arquivos, seu builder precisa carregar e filtrar cada conjunto de dados relacionado manualmente, um passo de cada vez, em vez de fazer uma pergunta e obter uma resposta — um banco de dados faz o mesmo trabalho em milissegundos com uma única consulta.

Digamos que você queira encontrar “todas as faturas não pagas de clientes na Califórnia que não foram contatados na última semana”. Com arquivos, seu builder precisa:

Carregar todas as faturas.
Filtrar por não pago = true.
Carregar todos os clientes e cruzar por ID.
Filtrar por estado = “CA”.
Carregar todos os registros de contato e cruzar por ID do cliente.
Filtrar por data > uma semana atrás.

Com um banco de dados, você escreve uma consulta e ela faz tudo isso em milissegundos.

Quando migrar para um banco de dados: quando seu builder disser “eu precisaria escrever código customizado para responder isso”. Ou quando você perceber que o app está fazendo muito esforço só para mostrar dados filtrados.

O que devo dizer ao meu builder quando eu precisar de um banco de dados?

Diga claramente o que está dando errado e peça um plano — algo como: “O app está [mais lento/perdendo dados/precisando de buscas mais complexas]. Acho que devíamos adicionar um banco de dados. Quão grande é essa mudança?”

A maioria dos builders consegue migrar um app de arquivos para um banco de dados em 1 a 2 dias para apps pequenos, alguns dias para os maiores. O processo é:

Manter o app praticamente igual (os usuários não vão notar uma grande mudança).
Conectar um backend de banco de dados (ainda parece arquivos para o resto do código, mas por baixo é um banco de dados).
Testar bastante (porque mover dados é uma operação delicada).
Rodar os dois em paralelo por uma semana até você ficar confiante.

O builder pode perguntar:

“Devemos usar PostgreSQL, MySQL, ou outra coisa?”
- Sua resposta: “O que você tiver mais confiança para usar. Eu não sei a diferença, mas confio em você.”
“Isso vai levar 3 dias. Vale a pena?”
- Sua resposta: “Se precisamos migrar de qualquer forma, quanto antes melhor, antes que haja mais dados.”
“Devemos migrar os dados antigos?”
- Sua resposta: “Sim, a menos que sejam menos de 100 registros — aí começar do zero está ótimo.”

Eu preciso entender de bancos de dados?

Não — você não precisa saber o que é um banco de dados, aprender SQL, ou comparar PostgreSQL com MySQL. Tudo o que você precisa dizer ao seu builder é: “Duas pessoas podem usar o app ao mesmo tempo sem perder o trabalho uma da outra.”

Só isso. Seu builder pode escolher o banco de dados. Um simples como SQLite (para um app pessoal ou de equipe com menos de 10 usuários simultâneos) ou PostgreSQL (para algo maior) — ambos cumprem esse papel.

Como sei se meu app precisa de um banco de dados?

Marque quais destes quatro se aplicam a você — duas ou mais caixas marcadas significa que é hora de adicionar um banco de dados agora.

Lentidão: o app parecia mais rápido há 3 meses, parece mais lento agora. O arquivo de dados tem mais de 20 MB ou mais de 10.000 registros.
Perda de dados: as mudanças de alguém desapareceram, ou vários usuários relataram edições sumidas.
Complexidade: você quer fazer perguntas do tipo “me mostre X filtrado por Y” e o builder diz “isso é difícil de fazer com arquivos”.
Usuários: mais de uma pessoa está usando o app ao mesmo tempo (mesmo que ocasionalmente).

Se você marcou duas ou mais caixas, seu app está pronto para um banco de dados.

Se você marcou zero caixas, seus arquivos estão ótimos. Continue com eles. Simplicidade tem valor.

Se você marcou uma caixa, pergunte ao seu builder: “Isso é rápido o suficiente para conviver por mais 6 meses?” Se sim, espere. Se não, migre agora.