Porque É que Cada App do Mythex Tem a Sua Própria Base de Dados

Quando uma app que construis no Mythex precisa de guardar dados — registos, marcações, encomendas —, o Mythex dá a esse projeto a sua própria base de dados Postgres. Não uma tabela numa base de dados partilhada, nem um schema ao lado do de outra pessoa: uma base de dados separada, criada sob pedido, que adormece quando ninguém a usa. Eis porque a construímos assim, e o que custa.

O que recebes

Quando pedes dados ("guarda emails da lista de espera", "guarda marcações") ou usas o comando /database, o Mythex:

• cria uma base de dados Postgres dedicada para o projeto (atualmente Postgres 17),
• injeta os detalhes de ligação no teu espaço de trabalho e na tua app publicada como variáveis de ambiente, para que nunca apareçam no teu código, e
• deixa o agente criar tabelas e ler e escrever dados por ti.

A mesma base de dados é usada pela pré-visualização ao vivo e pela app publicada. Adormece após 5 minutos inativa e acorda com a consulta seguinte. As novas bases de dados começam pequenas e podem escalar sob carga, com um teto para que uma consulta descontrolada não cresça sem limite. Mais na documentação das bases de dados.

Porque não uma grande base de dados partilhada?

Uma base de dados partilhada com uma coluna que indica a que app pertence cada linha é mais barata de executar e mais simples de operar. Escolhemos não o fazer por quatro razões.

1. Isolamento em que não tens de confiar

O código escrito por IA comete erros. Numa base de dados partilhada, um WHERE app_id = … que faltasse numa consulta de uma app poderia ler ou sobrescrever os dados de outro cliente. Com uma base de dados por app, não há dados de nenhum outro cliente ao alcance — um erro fica dentro da sua própria app.

2. É um Postgres a sério, não uma camada proprietária

A tua app fala Postgres padrão com uma string de ligação normal. Qualquer biblioteca, ORM ou ferramenta que funcione com Postgres funciona aqui. Se exportares o teu projeto para o correr noutro lado, ele espera uma base de dados Postgres — algo que qualquer fornecedor de alojamento oferece — e não uma API específica do Mythex.

3. Cada app pode ter a forma de que precisa

Uma app quer uma tabela bookings com uma restrição única nos horários; outra quer pesquisa de texto completo sobre produtos. Com a sua própria base de dados, o schema e as migrações de cada app são assunto seu. Nada tem de caber num desenho do menor denominador comum.

4. O custo acompanha o uso

Como cada base de dados adormece por conta própria, uma app que ninguém usa custa quase nada, e o custo de uma app movimentada aparece como uma linha própria. O uso de bases de dados publicadas é faturado a partir do que a base de dados realmente mediu — como funciona essa faturação.

Os compromissos

Este desenho não é gratuito:

• Arranques a frio. Uma base de dados adormecida demora um momento a acordar na primeira consulta depois de um período calmo. Para a maioria das apps isto quase não se nota; para uma app que tem de responder de imediato a qualquer hora, é uma consideração.
• Custos com a base de dados acordada sem uso. Uma base de dados fica acordada enquanto alguma coisa lhe fizer consultas. Uma app que consulta a base de dados a cada poucos segundos a mantém acordada 24 horas por dia e custa mais do que uma que consulta sob demanda. Se o teu uso parecer mais alto do que esperavas, é normalmente por isto — pede à IA que pare de fazer polling e que carregue os dados quando forem precisos.
• Mais peças móveis para nós. Criar, acompanhar e limpar milhares de bases de dados dá mais trabalho do que uma só. Esse problema é nosso, não teu.

Se és novo em bases de dados

Uma base de dados é onde uma app guarda o que precisa de se lembrar. Se a ideia for nova, começa por o que é uma base de dados e o que é o Postgres. Quando estiveres pronto para construir algo que guarde dados, como construir uma app com IA explica como a acrescentar.