Visão geral
Paridade de dados entre backends, quando o schema é criado e links para Supabase e Firebase.
O Kasy cria só o schema das features que você escolheu no kasy new (modo Rápido ou Avançado). Com kasy add <feature>, entram tabelas ou coleções daquela feature.
Não renomeie tabelas, coleções nem campos. Os nomes estão em inglês de propósito. O app usa esses identificadores exatos.
Onde está cada coisa
| Página | Conteúdo |
|---|---|
| Supabase | Tabelas Postgres, campos principais, lista do modo Rápido |
| Firebase | Caminhos Firestore e o que cada coleção guarda |
| Edge Functions | Functions servidor no Supabase |
| Cloud Functions | Functions servidor no Firebase |
| Secrets | Chaves de API nos dois backends |
Quando o schema aparece
| Momento | O que acontece |
|---|---|
kasy new (Rápido) | Base + features marcadas abaixo, exceto Drive |
kasy new (Avançado) | Só o que você marcou |
kasy add <feature> | Schema daquela feature |
| Supabase | Tabelas visíveis após db push |
| Firebase | Coleções visíveis após o primeiro documento gravado |
Modo Rápido (dados)
Feedback, Stripe, RevenueCat, Ads, AI Chat, Kanban + base. Sem Drive. Facebook não cria tabela (só edge function).
API REST
O backend API não roda migrations Supabase nem cria coleções Firestore de dados do app. Você implementa no seu servidor o mesmo modelo que o código Dart espera. Use as páginas Supabase e Firebase como mapa de conceitos.
Push pode usar um projeto Firebase companheiro (FCM), como no Supabase.
Mesmo conceito, nomes diferentes
| Conceito | Firebase | Supabase |
|---|---|---|
| Avatar | avatarPath | avatar_url |
| Notificação lida | seen_date | read_date |
| SKU da assinatura | product_id | sku_id |
| Fim do período | expiration_date | period_end_date |
| Ordem no Kanban | order | position |
O app mapeia isso na camada api/. Não altere no banco.
Veja também Backends e Comandos.
Atualizado em 03/11/2026