Glossário Admin | SuperDB Docs

owner (dono do projeto)

Definição: A conta SuperDB que criou o projeto e responde por ele — plano, faturamento e quem mais pode colaborar.

Contexto: Não confunda com os usuários do seu app, que vivem dentro do projeto e entram pelo db.auth. Para dar acesso ao dashboard a mais alguém do seu time, use Time no menu do projeto.

project

Definição: Unidade de isolamento no SuperDB. Cada projeto tem um schema Postgres exclusivo, um conjunto de buckets de storage, configurações de auth independentes e API keys próprias.

Contexto: Criado pelo dashboard ou via POST /platform/v1/projects. O slug do projeto define o nome do schema: proj_<slug>.

-- Schema do projeto "acme": proj_acme.users, proj_acme.orders, ...

schema

Definição: Namespace do PostgreSQL que isola tabelas, views e funções. No SuperDB cada projeto tem seu próprio schema, evitando colisões de nomes entre clientes.

Contexto: Schemas especiais do sistema: auth_global (usuários da plataforma), proj_management (metadados de projetos), proj_<slug> (dados do projeto).

SET search_path TO proj_acme; SELECT * FROM users;

tenant

Definição: Cliente de um SaaS que usa SuperDB como infraestrutura. Em arquiteturas multi-tenant com Groups, cada tenant tem seu próprio schema isolado clonado a partir de um template.

Contexto: Usado no contexto de SaaS Factory: um ISV (Independent Software Vendor) tem um Group com vários tenants — um por cliente final.

-- Schema do tenant "empresa-xyz" no group "meu-saas": proj_meu-saas_empresa-xyz.tabela

bucket

Definição: Contêiner de arquivos no SuperDB Storage. Similar a um bucket S3. Pode ser público (leitura livre) ou privado (requer autenticação e signed URL).

Contexto: Cada projeto pode ter múltiplos buckets. Configurações de CORS, tamanho máximo de arquivo e mime types são definidas por bucket.

// Bucket público — avatar { "name": "avatars", "public": true } // Bucket privado — documentos { "name": "documentos", "public": false }

hook

Definição: Função que é disparada automaticamente em resposta a eventos de autenticação. Exemplos: enriquecer o JWT com claims customizados, enviar webhook após signup, bloquear login por IP.

Contexto: Configurados em Auth → Hooks no dashboard. Suportam funções Postgres (via pg_net) ou endpoints HTTP externos.

-- Hook: adicionar role ao JWT após login CREATE FUNCTION auth.custom_claims(event jsonb) RETURNS jsonb AS $$ SELECT event || '{"claims": {"role": "admin"}}'::jsonb; $$ LANGUAGE sql;

advisor

Definição: Sistema de análise automática que varre o schema do projeto em busca de problemas de performance e segurança. Sugere índices faltantes, policies RLS ausentes e configurações inseguras.

Contexto: Visível em Database → Advisor no dashboard. Roda automaticamente uma vez por dia ou sob demanda.

-- Exemplo de alerta do Advisor: "Tabela proj_acme.orders não tem RLS ativado. Usuários anon podem ler dados de todos os clientes."

group

Definição: Coleção de projetos agrupados sob um ISV ou produto SaaS. Um Group define um schema template que é clonado para cada novo tenant provisionado.

Contexto: Criado pela API de plataforma; os tenants são provisionados com a Group API Key (sdb_gk_…). Cada Group tem um slug único e pode conter dezenas ou centenas de tenants.

Group "meu-saas" (slug: meu-saas) ├── Tenant: cliente-a → schema proj_meu_saas_cliente_a ├── Tenant: cliente-b → schema proj_meu_saas_cliente_b └── Tenant: cliente-c → schema proj_meu_saas_cliente_c

provisioning

Definição: Processo de criar e configurar automaticamente a infraestrutura para um novo tenant: clonar o schema template, criar roles Postgres isoladas, configurar RLS e GRANTs.

Contexto: Disparado pelo dashboard (Groups → Tenants → Novo) ou via POST /platform/v1/groups/:slug/tenants. Tempo médio: 1–3 segundos. Idempotente: chamar duas vezes não duplica.

POST /platform/v1/groups/meu-saas/tenants { "slug": "cliente-d", "display_name": "Cliente D Ltda" } // Resultado: schema proj_meu-saas_cliente-d criado // com todas as tabelas do template + roles isoladas