Supabase para projetos sérios: limites e suporte falho

O Supabase parece uma solução freemium interessante no primeiro contato, mas na prática não é viável para projetos sérios. Uso a plataforma e o que pesa é a soma de três problemas recorrentes: limites de uso novos aparecendo quase todo mês, um suporte por e-mail incluído no plano pago que responde com modelo pronto e não investiga nada, e falhas de infraestrutura que geram incidentes grandes. A base técnica é boa, mas o conjunto não sustenta operação crítica.

Limites de uso que aparecem quase todo mês

O ponto que mais me incomoda é a mudança constante das regras de consumo. A plataforma vai acrescentando novos limites de uso com o passar dos meses, e isso acontece depois que o projeto já está rodando em cima dela. Quem começou com uma expectativa de custo e de capacidade precisa rever planejamento com frequência, sem saber o que vem na próxima atualização. Para quem trabalha com previsibilidade, esse modelo de limites móveis é desgastante, porque o desenho da arquitetura nunca fica estável.

Não estou falando de um ajuste pontual, e sim de um padrão: a cada ciclo aparece alguma regra nova de consumo que muda o que o plano comporta. Isso transforma uma decisão técnica em uma decisão que precisa ser reavaliada sempre. Em um projeto sério, com previsão de crescimento e orçamento fechado, esse tipo de variação atrapalha mais do que ajuda. O discurso de solução freemium amigável não se sustenta quando os limites continuam se movendo por conta da plataforma, e não por conta do meu uso.

Suporte por e-mail incluso que não soluciona nada

Quando fiz o upgrade, a promessa era clara: o suporte por e-mail estava incluído no plano pago. O canal existe, responde, mas na prática é inútil. O atendente que me respondeu não fez o mínimo de investigação do problema, não fez troubleshooting e nem sequer tentou usar recursos automatizados para localizar a causa. Recebi uma resposta de modelo pronto, daquelas que servem para fechar o ticket e não para resolver o que foi relatado. Voltei com mais detalhes e o resultado foi o mesmo padrão de texto, sem diagnóstico.

Isso muda completamente a leitura que faço do plano pago. Pagar por suporte pressupõe que alguém vai olhar o caso, tentar reproduzir, apontar hipótese e seguir com um caminho de solução. O que encontrei foi um canal formalmente disponível e operacionalmente vazio. Se o problema é simples, talvez o modelo pronto baste. Se o problema é real, o suporte por e-mail não sustenta a operação e me obriga a resolver tudo por conta própria, estudando a plataforma no meio de um incidente.

Infraestrutura instável com problemas de impacto

O terceiro ponto é a infraestrutura. Com frequência aparecem problemas do lado da plataforma que geram incidentes grandes, e o acompanhamento é feito pela página de status do próprio serviço. Ou seja, a origem da falha está no fornecedor e a resposta que tenho é consultar um painel público para entender o tamanho do estrago. Para quem depende da plataforma em produção, esse tipo de ocorrência consome tempo de equipe e gera retrabalho, porque a causa não está no meu código e a correção também não está nas minhas mãos.

Somando as três coisas, o retrato fica claro: as falhas de infraestrutura chegam sem aviso, os limites de uso mudam por decisão do fornecedor e o suporte incluído não investiga. Cada um desses fatores isoladamente dá para administrar. Juntos, formam um ambiente em que eu não consigo garantir estabilidade nem previsibilidade de custo para um projeto sério.

No fim, o produto tem méritos e a proposta inicial é atraente, mas a experiência real não acompanha a promessa de freemium. Os limites de uso que não param de crescer, o suporte por e-mail que responde com modelo pronto e os problemas recorrentes de infraestrutura formam um conjunto que eu não indicaria para um negócio sério. Serve bem para estudo, protótipo ou projeto pessoal, onde a mudança de regra não derruba operação. Para algo que precisa ficar no ar e ser previsível, prefiro não apostar.