Porque usamos Cloudflare KV para a waitlist

Quando precisámos de um backend para a waitlist do Lyrify Music, avaliámos três opções: Firebase, Supabase e Cloudflare KV. Cada uma tem prós e contras — mas a escolha foi mais óbvia do que parecia.

O que precisávamos

A waitlist é simples: um formulário que guarda emails e uma API protegida que os devolve. Sem autenticação de utilizadores, sem relacionamentos complexos, sem WebSockets. Apenas ler e escrever JSON.

Porquê não Firebase

O Firebase Realtime Database ou Firestore seriam overkill para o nosso caso. Além disso, o ecossistema Google traz dependências pesadas e a camada gratuita tem limites que podíamos esgotar rápido com múltiplos projectos.

Porquê não Supabase

O Supabase é excelente, mas é PostgreSQL — uma base relacional completa para um problema que é essencialmente um par chave-valor. Preferimos algo mais leve e que se integrasse nativamente com o nosso host (Cloudflare Pages).

Cloudflare KV: a escolha natural

O Cloudflare KV é um armazenamento chave-valor global, com leituras extremamente rápidas (milissegundos) e uma generosa camada gratuita: 1 milhão de leituras e 1 milhão de escritas por mês — mais do que suficiente para uma waitlist.

A integração com Pages Functions é imediata: o KV fica disponível no objecto env sem configuração adicional. Em menos de 10 linhas de código tinhamos a API a funcionar.

"Menos plataforma, mais produto. KV resolve o problema sem introduzir complexidade."

Estruturámos os dados como um array JSON numa única chave (emails), o que simplifica a leitura e escrita. Para o volume esperado (centenas, não milhões), é mais que suficiente.