FAQ para devs.

Node 18+, qualquer framework JS (Next.js, Remix, SvelteKit, Astro, etc.) e o pacote @superdb/client. Funciona em projeto frontend-only (chamando a API do client) ou backend (server-side com service-role).

Não precisa de Postgres local pra desenvolver — o projeto remoto gratuito já vem pronto. Pra dev local com Docker, veja a próxima pergunta.

Sim. O SDK é framework-agnostic. Importe createClient e use. Não tem hook, plugin nem build-step exigido por framework específico.

npm install -g @superdb/cli && superdb start. Sobe Postgres, Auth, REST (PostgREST) e Studio em containers locais. Tudo escutando em localhost e idêntico em comportamento ao prod. Só que o pacote @superdb/cli ainda não foi publicado no npm — por enquanto o caminho é o painel em app.superdb.com.br.

Pra desenvolvimento local sim — a CLI usa Docker Compose por baixo. Em produção, é gerenciado: você não cuida de container nenhum.

JS/TS é o oficial hoje. Pra outras linguagens, a API REST direta funciona — qualquer cliente HTTP serve. Wrappers Python/Go community estão na roadmap.

Quase. .auth, .from() e .storage têm os mesmos nomes de método, e desde a versão 0.3 do SDK também onAuthStateChange, updateUser, upsert e a renovação sozinha da sessão. O realtime usa o @supabase/realtime-js com o token do SuperDB (o .channel() do SDK só avisa isso). Edge Functions ainda não existem no SuperDB, e não há data. Veja o guia de migração pra detalhes.

O SDK vem tipado: import type { User, Session } from '@superdb/client'. Os tipos das suas tabelas você declara à mão — não existe gerador de tipos a partir do schema, e o .from() não aceita parâmetro de tipo. Anote o resultado: const tarefas = (data ?? []) as Tarefa[].

Quase nada: policies, triggers, funções e RPC rodam no mesmo PostgreSQL 15, e auth.uid(), auth.jwt() e auth.role() se comportam como no Supabase. Duas diferenças costumam exigir ajuste:

• Não existe auth.users: os usuários ficam na tabela auth_users do schema do projeto, e as chaves estrangeiras passam a apontar para ela.
• O token não carrega app_metadata nem user_metadata. Policies que leem papel ou permissão do JWT passam a ler de uma tabela.

Passo a passo em Migrar do Supabase.

No banco de cada projeto já vêm instaladas: vector (pgvector), postgis, pgcrypto, pg_trgm, citext, unaccent e uuid-ossp. Precisa de outra? Peça pelo suporte, que conferimos.

Não. Para tarefas agendadas, use um agendador fora do banco (o cron do seu backend ou os Cron Triggers do Cloudflare Workers) chamando uma função via RPC. Para chamar uma API externa a partir de uma mudança no banco, faça a chamada no seu backend.

Sem o pg_net, os Database Webhooks do Supabase não migram: eles são um gatilho que chama net.http_post, e essa chamada não sai do banco de um projeto aqui. Há dois caminhos: a sua aplicação chama a URL logo depois de gravar; ou um gatilho grava o evento numa tabela sua, e um worker (o seu backend ou um Cloudflare Worker) lê essa tabela e chama a URL.

Com um endpoint seu: um Cloudflare Worker, uma função da Vercel ou o seu backend recebe o webhook (Mercado Livre, Stripe, Asaas e outros) e grava no SuperDB pela API REST com a chave service_role, que fica só no servidor. O SuperDB não executa código seu na plataforma.

Sim. Na tela de usuários do projeto (Autenticação), enquanto ela está vazia, o painel mostra o comando que exporta os usuários do Supabase e o botão que importa o arquivo. Cada usuário mantém o id e entra com a mesma senha, que no primeiro login passa a ser guardada em Argon2id. Quem usava MFA cadastra o autenticador de novo.

Sim: o realtime do SuperDB é o próprio Supabase Realtime, então postgres_changes, presence e broadcast funcionam com o @supabase/realtime-js. O que muda:

• O app pede um token de realtime com a sessão do usuário e conecta o realtime-js direto. O channel() do nosso SDK ainda não está disponível.
• Cada tabela é habilitada na tela Realtime do painel e precisa de RLS.
• O schema é o do projeto, não o public.

Numa tabela sua, cifrada: com pgcrypto no banco ou cifrando na aplicação, e com RLS que não deixa a chave anon ler. Ainda não há um cofre gerenciado de segredos, e a rotação dos tokens fica com a sua aplicação.

Sim. O MCP remoto usa OAuth: na autorização você escolhe quais projetos aquele agente alcança, e pode revogar a qualquer momento em Conta › Aplicativos conectados. Como as ferramentas incluem SQL que altera o projeto, conecte o agente só aos projetos de desenvolvimento ou de homologação. Detalhes na página do MCP.

Qualquer um: Vercel, Netlify, Cloudflare Pages, Railway, Fly. O backend (DB + Auth + Storage) é gerenciado pelo SuperDB e você só consome via SDK ou REST.

Sim, pela API. Um passo do GitHub Actions no PR mergeado manda o SQL das suas migrations para POST https://auth.superdb.com.br/platform/v1/projects/<id>/db/exec com a management key do projeto, guardada nos secrets do repositório. Crie essa chave com a conta do dono do projeto: a chave vale enquanto quem a criou for owner ou admin, e a de um membro que sai do time (ou vira member) para de funcionar na hora. A CLI ainda não foi publicada, então não há comando superdb para isso.

Sim, com o SDK rodando em runtime edge (compatível). Edge Functions do próprio SuperDB não existem, e não há data para existirem.

Sim, NUNCA exponha service-role no frontend. Vai vazar tudo — service-role ignora RLS. Use anon no client. Veja service vs anon.

Dashboard > Settings > API Keys > Regenerate. Atualize as envs nos servidores que usam (Vercel/Render/CI) imediatamente após — a antiga é invalidada na hora.

Sim. Armazenado encriptado AES-256, único por projeto, rotacionável pelo dashboard. A rotação invalida sessões ativas — avise seus users antes.

Sim. Auth tem hash chain auditável (cada evento liga ao hash do anterior — não dá pra mexer no meio sem detectar). Storage e DB audit estão em breve.

Servidor em São Paulo, e só lá: não há outras regiões, nem no prazo curto. Quanto mais longe de São Paulo o usuário, mais demora cada requisição. Não publicamos número de latência porque não medimos de cada região; meça do seu app com uma requisição simples (curl -w '%{time_total}').

Não há PgBouncer. O SDK e a API REST passam pelo PostgREST, que mantém o próprio pool de conexões com o banco: o seu app não abre conexão nenhuma. Conexão direta ao Postgres não é oferecida: o banco não fica aberto na internet. SQL roda pelo editor do painel ou pela API com a management key.

EXPLAIN ANALYZE no Studio > SQL Editor. Identifique seq scans em tabelas grandes e adicione índices nos filtros mais usados (CREATE INDEX ON tbl(coluna)). Pra realtime, evite filtros caros — preferir filtrar do lado client após receber.

Studio > Logs > Realtime, filtra por query (PostgREST). Vê o SQL traduzido linha por linha, com tempo e params. Útil pra descobrir por que .eq() não filtra o que você esperava.

Studio > Authentication > Policies (ou tabela > "Show row level security"). Vê qual política está aplicando. Pra testar direto: SET ROLE authenticated; SELECT * FROM tbl; no SQL editor.

É WebSocket — abra DevTools > Network > WS pra ver o handshake. Firewall corporativo às vezes bloqueia. Cheque também se o canal está habilitado em Dashboard > Database > Replication.

É de propósito: cada execução do Editor já roda inteira numa transação, então o script é atômico sem BEGIN, COMMIT ou ROLLBACK (se algo falhar no meio, nada fica aplicado). Tire esses comandos e rode de novo; DDL como create table funciona normalmente.

Cadastre o endereço do seu app em Autenticação › URLs de redirecionamento. O link do e-mail só volta para um endereço cadastrado: sem nenhum, o SuperDB recusa o redirecionamento em vez de mandar o usuário para um lugar errado.

Veja a página de status. Se ela estiver normal e o erro continuar, abra um chamado em Conta › Suporte com o horário e a mensagem de erro: o suporte confere nos logs do servidor.