FAQ para gestor / tech lead.

Tabela simples (todos valores em BRL/mês):

A partir de 14/11/2026, o Grátis também tem 250.000 requisições por mês em cada projeto. Um app em produção, com uso todos os dias, costuma passar disso: aí o plano certo é o Site, que não tem cota de requisições por mês.

Já inclui infra e suporte (com prazo de resposta por plano). Sem cobrança por leitura ou escrita: o preço é fixo, e só o que passar do limite do plano é cobrado à parte — valores em Preços. SLA contratual não está incluído (veja abaixo).

Real (BRL). Sem IOF, sem câmbio variável, sem dolarização do orçamento.

Mandamos lembretes por e-mail 1, 3, 7 e 14 dias depois do vencimento, com o link da fatura. Antes de qualquer suspensão por atraso, avisamos e damos prazo para regularizar — é o que os Termos garantem (seção 7).

Depende muito do uso. Comparativos diretos em /docs/comparar/. Geralmente: ~30-50% mais barato que Supabase (sem dolarização), ~70-90% mais barato que Firebase (no caso de muitos reads/writes), e bem menos imprevisível que AWS pay-per-use.

Sim. O banco é Postgres puro: a pedido pelo suporte, a equipe gera o dump do seu projeto (schema e dados, com pg_dump) e a cópia dos arquivos, e qualquer host com Postgres roda. Sem amarração contratual. Tabelas avulsas você exporta em CSV pelo SQL Editor.

Hoje não. O código está licenciado sob AGPL-3.0, mas o repositório ainda é privado e não há data para abrir. Enquanto isso, o SuperDB é um serviço gerenciado. O que não muda: seu banco é Postgres puro, a gente gera o pg_dump completo do seu projeto sob pedido, e pela API você lê e exporta os seus dados quando quiser.

Sim, com ajuste. As consultas de dados seguem os nomes do supabase-js: troca o createClient para o de @superdb/client e acrescenta o projeto. O que muda é o jeito de o servidor ler a sessão, e poucos métodos (como a troca de e-mail) que o SDK ainda não tem. Schema é Postgres puro, então sair também é possível: o dump volta para qualquer Postgres. O que muda está no guia de migração.

A LGPD se cumpre no conjunto, e boa parte dele é seu: você é o controlador e decide quais dados coletar, a base legal e por quanto tempo guardar. O que o SuperDB entrega como operador: ferramentas para exportar e excluir os dados do titular, trilha de auditoria encadeada por hash, dados hospedados em São Paulo e isolamento entre projetos pelo banco, com RLS. O que não é cifrado e o que ainda não temos estão em Segurança, e o DPA está em LGPD e proteção de dados.

Não. Não temos ISO 27001 nem SOC 2, e não há auditoria em andamento — seria desonesto dizer "em processo". Hoje os controles seguem LGPD e as práticas do NIST CSF, e a página de segurança lista o que temos e o que não temos. Se a sua empresa exige o certificado em mãos, o SuperDB ainda não atende esse requisito.

Banco e arquivos ficam em servidor no Brasil, em São Paulo (Hostinger Brasil). Duas coisas saem daqui, e estão na Política de Privacidade: as cópias de backup, cifradas, ficam no Cloudflare R2, que pode replicá-las fora do Brasil; e os e-mails do sistema saem por um provedor nos EUA. Pra empresas com soberania de dados rígida (governo, saúde, financeiro regulado), vale conferir esses dois pontos antes de decidir.

Depende da camada. TLS 1.2 ou superior em todo o tráfego público. Senhas em Argon2id. CPF/CNPJ do titular e os segredos de cada projeto em AES-256-GCM. Backups do banco e dos arquivos cifrados antes de sair do servidor. As tabelas do seu app ficam em texto (o disco não é cifrado): quem as protege é o controle de acesso: banco próprio, papel exclusivo por projeto e RLS. Detalhe camada por camada em Segurança.

Ainda não. Não contratamos pentest externo até agora: as revisões de segurança são feitas por nós, e os achados e as correções ficam registrados. Se o seu processo exige relatório de pentest de terceiro, fale com a gente antes de decidir.

Sim, em qualquer plano e sem custo. É opcional: ligamos no projeto a pedido, pelo suporte. Ligada, ela vale no cadastro, na troca de senha e na redefinição pelo link de "esqueci a senha": nos três casos, a senha nova que aparece em vazamento conhecido é recusada. Só os 5 primeiros caracteres do hash SHA-1 da senha são consultados no Have I Been Pwned; a senha nunca sai da plataforma.

Pelo suporte: a equipe restaura o banco do projeto a partir de um backup dentro da retenção do plano (7 dias no Site, 30 no Pro, 90 no Escala). Não há restauração point-in-time. Antes de uma mudança arriscada, vale também um pg_dump seu.

Em até 48 horas a partir da constatação, com o que se sabe até então, como está no DPA.

Depende do tamanho do pico. Tudo roda em um servidor em São Paulo, sem réplica e sem escala automática, e a API tem um limite de requisições por segundo em cada plano (veja a página de preços). Se você espera um pico grande, como uma Black Friday, fale com a gente pelo suporte antes.

Nos planos self-serve (Grátis, Site, Pro e Escala), não há SLA contratual nem crédito por indisponibilidade. A plataforma roda numa instância única, sem réplica com troca automática, e a gente prefere dizer isso a vender um número que não sustenta. Se SLA contratual é requisito do seu projeto, fale com a gente antes de decidir.

Todo mundo abre chamado pelo painel, inclusive no plano grátis. O que muda é o prazo de resposta, em horas úteis: grátis por ordem de chegada, Site em até 48h, Pro em até 24h e Escala em até 4h. Tudo em PT-BR.

Depende do app: o banco é a parte previsível (pg_dump, que a gente restaura junto com você); a camada de login do app é a que pede trabalho. Os usuários você mesmo importa no painel, com o mesmo UUID e a mesma senha. Database Webhooks e o pg_cron não vêm junto: o que chamava uma URL ou rodava agendado de dentro do banco passa para a sua aplicação. Guia passo a passo em /docs/guias/migrar-supabase.

1-5 dias dependendo do tamanho. Paradigma muda (NoSQL Firestore → relacional Postgres), então tem trabalho de modelagem. Guia detalhado em /docs/guias/migrar-firebase.

Os usuários migram no primeiro login, com a mesma senha, enquanto o Auth0 continua no ar: o seu servidor confere a senha lá e cria a conta aqui. O hash do Auth0 não é importado, porque o login do SuperDB só confere Argon2id. Guia em /docs/guias/migrar-auth0.

Hoje Felipe Padilha (fundador e dev principal), pela Comissário Software House LTDA (CNPJ 68.842.056/0001-27), de Belo Horizonte/MG.

Risco existe, como em qualquer startup — e não vamos vender o código aberto como seguro, porque hoje o repositório é privado. A mitigação real é o formato: é Postgres puro, sem camada proprietária no meio. A gente gera o pg_dump completo sob pedido, a API lê os seus dados a qualquer momento, e o dump sobe em qualquer host Postgres do mercado. O storage é S3-compatível. A saída não depende de nós continuarmos existindo.

O foco hoje é o serviço gerenciado: cobrança em real e a operação do dia a dia. pgvector e PostGIS já estão disponíveis no Postgres; o pg_cron não (cada projeto tem o próprio banco, e o agendamento de tarefas fica fora dele). Edge Functions, multi-region e certificações continuam fora do prazo curto — quando entrarem, entram aqui e no /blog, não antes.