O engine, sem camada no meio
PostgreSQL 18 na porta 5432, MySQL 9.7 na 3306, MongoDB 8.0 na 27017 e Redis 8.2 na 6379. Driver, ORM e ferramenta de migração falam com a instância como com qualquer instalação dessas versões.
PostgreSQL 18 e 17, MySQL 9.7 e 8.4, MongoDB 8.0 e 9.0 e Redis 8.2 e 7.2 criados pelo painel em minutos. Cada banco sobe com host, porta, usuário, senha e certificados prontos — a conexão só acontece por TLS.
Comportamento padrão de qualquer banco criado aqui: nada nesta lista precisa ser configurado.
PostgreSQL 18 na porta 5432, MySQL 9.7 na 3306, MongoDB 8.0 na 27017 e Redis 8.2 na 6379. Driver, ORM e ferramenta de migração falam com a instância como com qualquer instalação dessas versões.
Você define quanta RAM do plano vai para o banco e pode mudar isso depois. O container reinicia com o novo limite; host, senha e certificados continuam os mesmos.
Cada banco roda no seu próprio container, na rede interna da plataforma. Nada nele é compartilhado com outro cliente, e o acesso de fora exige TLS.
Em todos os planos: snapshot manual quando você quiser, restauração de qualquer snapshot anterior com cooldown de 30 segundos e download do conteúdo em ZIP.
Escolha o engine e a memória; o painel devolve host, porta, usuário, senha e os certificados TLS para baixar. Não há servidor para provisionar nem CA para manter.
Nos planos com o editor de dados: tabelas, coleções, chaves e TTL abertos direto no dashboard, com console SQL — sem expor a connection string nem instalar cliente.
Para criar um banco, seu plano precisa ter RAM livre para alocar a ele:
A memória do banco sai da RAM do seu plano e fica indisponível para as aplicações enquanto ele existir.
Mesmo painel, mesmos certificados, outro engine.
O que costuma ser perguntado antes de criar o primeiro banco
A plataforma cria o container, gera a CA e os certificados TLS, expõe o host e mantém o engine de pé. Você recebe as credenciais e cuida só dos seus dados — não há servidor para provisionar, pacote para atualizar nem certificado para renovar na mão.
No painel, escolha o engine (PostgreSQL, MySQL, MongoDB ou Redis) e quanta memória do plano vai para ele. Em alguns minutos o banco está de pé, com host, porta, usuário, senha e os certificados disponíveis para download.
Redis para cache, sessão e fila; MongoDB para documento que muda de forma; PostgreSQL para consulta que cruza tabelas com transação; MySQL quando o projeto já espera MySQL. A página de cada engine tem o detalhe.
Em todos os planos o banco tem backup diário e snapshot manual: você tira um snapshot quando quiser, restaura qualquer um dos anteriores (com cooldown de 30 segundos entre restaurações) e pode baixar o conteúdo em ZIP. Não existe recuperação para um instante arbitrário no tempo — o que existe é o snapshot que foi tirado.
Sim. Altere a memória alocada, dentro do teto do plano, ou suba de plano para ter mais RAM. O container reinicia para subir com o novo limite, então as conexões abertas caem por instantes; host, senha e certificados continuam os mesmos.
Não publicamos uma cota de conexões por plano. O teto prático é a memória que você alocou: cada conexão aberta ocupa memória do container. Se a sua aplicação abre uma conexão por requisição, use um pool no lado dela — é o que segura carga sem aumentar a RAM do banco.
PostgreSQL, MySQL, MongoDB ou Redis pelo painel, com TLS obrigatório e certificados prontos para baixar.
Entrar para começar