PocketBase

O que o PocketBase é de fato

A maioria dos backends é trabalho de montagem: um banco de dados em algum lugar, um serviço de autenticação ao lado, um armazenamento de objetos para os uploads, um painelzinho de administração que você sempre pretende construir, e a cola entre tudo isso. O PocketBase reduz isso a um processo e um arquivo em disco. Você baixa um executável para a sua plataforma, roda, abre o painel no navegador, define suas coleções, e o seu aplicativo já tem uma API — sem orquestração de contêineres, sem banco gerenciado, sem fornecedor de autenticação à parte e sem nada para configurar antes da primeira requisição funcionar.

A troca é visível e proposital. Como o banco é embutido em vez de acessado pela rede, o backend inteiro é um processo segurando um arquivo SQLite, o que é exatamente o que o torna tão simples de operar e também o que faz da escala horizontal uma conversa diferente da de outras arquiteturas. Para o estágio em que está a maior parte de quem lê esta página — um aplicativo ainda sem usuários, ou com algumas centenas — essa troca pende bastante a seu favor, e continua assim por muito mais tempo do que as pessoas esperam.

• Um banco embutido com assinaturas em tempo real. SQLite dentro do binário, mais uma API de assinaturas para que os clientes recebam as mudanças conforme acontecem em vez de ficar perguntando. Uma interface que se atualiza sozinha vira o padrão em vez de virar um projeto.
• Usuários e arquivos, já embutidos. Autenticação e gestão de usuários vêm juntas, assim como o tratamento de arquivos, então os dois recursos que normalmente puxam um serviço de terceiros logo no primeiro dia já estão ali.
• Um painel de administração e uma API no estilo REST. Uma interface web para definir coleções, editar registros e inspecionar dados, sobre uma API HTTP que os SDKs oficiais encapsulam. O SDK de JavaScript cobre navegadores, Node.js e React Native; existe um SDK em Dart para Flutter e desktop.
• Um único executável portátil. Os binários pré-compilados usam um driver de SQLite escrito em Go puro e compilam com CGO desativado, então fazem compilação cruzada para uma lista publicada de alvos Linux, macOS, Windows, FreeBSD, OpenBSD e NetBSD. Publicar é copiar um arquivo e executá-lo.

Dois jeitos de rodar, e a escolha importa lá na frente

O primeiro é como aplicativo autônomo. Baixe a versão para a sua plataforma, extraia, rode o comando serve e pronto. Os executáveis pré-compilados também carregam uma máquina virtual de JavaScript, então dá para adicionar hooks e endpoints próprios em JavaScript sem encostar em Go nem recompilar nada. É o caminho que coloca um protótipo na frente de alguém ainda hoje à tarde, e ficar por aqui é perfeitamente razoável.

O segundo é como biblioteca Go. Você importa o PocketBase num programa seu, registra rotas e regras de negócio nos eventos de ciclo de vida dele, e compila o resultado — o seu código e o backend inteiro — em um único executável ligado estaticamente. O exemplo mínimo do próprio README tem cerca de quinze linhas. O motivo para saber disso no primeiro dia é que essa é a saída de emergência: o aplicativo autônomo não vira uma parede quando a sua lógica ultrapassa o que dá para configurar, porque o mesmo projeto também é o framework por baixo. Os requisitos são modestos, hoje Go 1.27 ou mais novo para compilar.

Onde ele entra na pilha de crescimento de um fundador

O PocketBase é uma ferramenta de construção, não de crescimento, então a contribuição dele para o crescimento é indireta e vale nomear com honestidade: ele elimina as semanas entre ter uma ideia e ter algo em que um estranho consiga entrar com login. Isso importa porque quase nada do que se aprende sobre demanda está disponível antes desse ponto. O que ele não faz é trazer alguém até aquilo que você construiu.

• Para uma primeira versão funcionando. Autenticação, armazenamento e banco em um download só é o caminho honesto mais curto de um protótipo até algo com um login de verdade na frente. Se você está fazendo o front com ferramentas de IA, qual a melhor forma de divulgar um app feito com vibe coding pega o bastão onde a construção para.
• Para ferramentas internas que você não quer pagar. Uma lista de espera, um calendário de conteúdo, um controle de prospecção, um CRM leve para as suas primeiras cinquenta conversas. Coleções mais o painel de administração cobrem uma quantidade surpreendente disso sem virar um produto para manter.
• Ao lado da camada de crescimento, não no lugar dela. Nada aqui escreve o seu posicionamento, publica coisa alguma ou responde a um cliente. Depois que o produto existe o trabalho muda de forma por completo — como consigo meus primeiros 100 usuários é o próximo problema, e é mais difícil.
• Saiba o que você está adotando. A licença é MIT e o README permite explicitamente o uso comercial, inclusive vender um serviço construído em cima dele. Também é pré-1.0 com mudanças incompatíveis esperadas, e o repositório está com pull requests temporariamente restritas a colaboradores existentes por causa de uma onda de envios automatizados de baixa qualidade — então conte com abrir issues em vez de patches.

O que aprendemos rodando SQLite em produção

Aqui a gente não é neutro, e essa é justamente a parte útil: a AgentCeres também roda SQLite em produção, então o que vem a seguir é uma decisão que tomamos, não uma resenha de fora. A coisa mais importante que um backend de arquivo único muda é que onde esse arquivo mora vira a sua arquitetura inteira. O nosso ficava num volume montado, e a falha com que a gente esbarrava sempre era que qualquer coisa que um contêiner tivesse escrito e que ninguém tivesse empurrado para um armazenamento durável simplesmente não sobrevivia ao próximo deploy. E nunca se anunciava como erro: aparecia como um aplicativo que tinha esquecido algo em silêncio, que é a pior forma possível de perda de dados chegar.

A segunda surpresa foi que o recurso escasso era o volume em si, não o espaço em disco dele. Nosso provedor limita a quantidade de volumes por projeto, e batemos nesse teto muito antes de qualquer limite de capacidade, o que acabou forçando uma reestruturação: os contêineres viraram descartáveis e o estado durável foi para um banco de dados mais armazenamento de objetos que sobrevivem a eles. Se você vai rodar um PocketBase para um produto, isso nunca vai te alcançar. Se você se pegar querendo um por cliente, conte os volumes antes de desenhar em cima deles.

A terceira é específica do SQLite e nos custou uma tarde genuinamente confusa. A tipagem do SQLite é flexível: tínhamos carimbos de tempo guardados como inteiros em algumas colunas e como texto em outras, e comparações entre essas duas formas não retornam erro nenhum — só as linhas erradas, em silêncio, numa consulta que se lê como correta. O PocketBase administra o próprio esquema, então você fica bastante protegido disso até começar a escrever as suas consultas ou as suas extensões em Go contra o mesmo arquivo, e aí o problema passa a ser seu. Decida o formato de armazenamento uma vez e confira o tipo da coluna antes de confiar numa comparação.