TL;DR
- Use Appwrite se: você quer SDK em Python/Dart/Kotlin/Swift, community grande, ou roda 100% self-hosted em qualquer infra hoje.
- Use SuperDB se: precisa de Postgres puro (SQL/RLS), features BR (cobrança em real, PIX, WhatsApp), os nomes de método do Supabase, suporte PT-BR humano.
Dica: os dois são open source — você pode rodar ambos pra testar no seu próprio hardware sem ter conta em nenhum. O Appwrite tem self-host hoje; o SuperDB ainda não abriu o código.
Feature por feature
| Feature | SuperDB | Appwrite | Observação |
|---|---|---|---|
| DB underlying | Postgres | MariaDB | — |
| SQL queries | ✓ completo | Limitado (collections API) | — |
| Row-level security | RLS nativo Postgres | Permissions em document level | SuperDB: mais poderoso |
| Auth providers | OAuth + WhatsApp OTP + CPF/CNPJ | OAuth + magic link | — |
| Functions | Não tem | ✓ várias linguagens | Appwrite: maduro hoje |
| Storage | Buckets + transformação de imagem | Storage + transformações | Empate |
| Realtime | Postgres changes + presence | Subscriptions a documents | Empate funcional |
| SDKs | TS/JS (hoje) | Python, Dart, Kotlin, Swift, JS, Flutter | Appwrite ganha aqui |
| Self-host | Não tem | ✓ hoje | Appwrite ganha |
| Comunidade | Crescendo | Grande, ativa | Appwrite ganha |
| License | AGPL-3.0 | BSD-3 | Ambas abertas |
| Foco geográfico | Brasil | Global | Diferentes mercados |
| Cobrança em BRL | ✓ | – | SuperDB único no BR |
| Pagamento em real (PIX, boleto ou cartão) | ✓ | – | SuperDB único no BR |
| Nomes de método do supabase-js | ✓ | – | Sem onAuthStateChange e updateUser; realtime pelo @supabase/realtime-js |
Quando Appwrite é melhor
- SDKs em Python/Dart/Kotlin/Swift hoje — se seu time é mobile-first com Flutter ou Swift nativo, Appwrite tem SDK first-party. SuperDB hoje atende via REST.
- Self-host hoje — Docker Compose pronto, deploy em qualquer VPS. O SuperDB ainda não abriu o código.
- Community maior — mais templates, mais Stack Overflow respondido, mais Discord ativo. Em 2026 a diferença ainda é considerável.
- Foco global — se seu app não tem nada de Brasil-específico, as features BR do SuperDB são overhead que você não usa.
Quando SuperDB é melhor
- App brasileiro — todas as features BR (BRL, PIX, CPF/CNPJ, WhatsApp OTP, dados em SP pra LGPD).
- Os nomes do Supabase — você já tem código
@supabase/supabase-js? Troque por@superdb/cliente ajuste o que a referência do SDK lista como diferente. Appwrite exige reescrever. - Postgres puro com SQL e RLS — joins, agregações, views materializadas, extensões (pg_trgm, postgis, etc). Appwrite com MariaDB é mais limitado em modelagem relacional avançada.
- Suporte PT-BR humano — Pro+ tem email priority em português, mesmo fuso horário.
Por que não os dois?
Sério — alguns times usam SuperDB pro backend web (Next.js, dashboard admin) e Appwrite pro mobile Flutter (SDK Dart first-class). Compartilham apenas o Postgres via FDW ou sync. É decisão de stack, não de seita.
Se você já tem investido em ferramentas Appwrite e elas funcionam, não migra à toa. SuperDB faz mais sentido em projeto novo BR ou em migração saindo de Supabase/Firebase.
Heurística: se a próxima coisa que você ia perguntar é "qual a engine de DB?" e você se importa com a resposta — SuperDB (Postgres) faz mais sentido. Se você só quer que "salve e leia documento" funcione, qualquer um serve.