PocketBase

Qué es PocketBase en realidad

La mayoría de los backends son un trabajo de montaje: una base de datos por un lado, un servicio de autenticación al lado, un almacén de objetos para las subidas, un pequeño panel de administración que siempre piensas construir, y el pegamento entre todo ello. PocketBase reduce eso a un proceso y un archivo en disco. Descargas un ejecutable para tu plataforma, lo ejecutas, abres el panel en el navegador, defines tus colecciones y tu aplicación ya tiene una API: sin orquestación de contenedores, sin base de datos gestionada, sin proveedor de autenticación aparte y sin nada que configurar antes de que funcione la primera petición.

El intercambio es visible y deliberado. Como la base de datos está embebida en vez de accesible por red, todo el backend es un proceso sujetando un archivo SQLite, que es justo lo que lo hace tan sencillo de operar y también lo que convierte el escalado horizontal en una conversación distinta a la de otras arquitecturas. Para la etapa en la que está la mayoría de quien lee esta página — una aplicación sin usuarios todavía, o con unos cientos — ese intercambio te favorece con claridad, y sigue haciéndolo mucho más tiempo del que la gente espera.

• Una base de datos embebida con suscripciones en tiempo real. SQLite dentro del binario, más una API de suscripciones para que los clientes reciban los cambios según ocurren en lugar de estar preguntando. Una interfaz que se actualiza sola pasa a ser lo normal en vez de un proyecto.
• Usuarios y archivos, de serie. La autenticación y la gestión de usuarios vienen incluidas, igual que el manejo de archivos, así que las dos funciones que suelen obligarte a contratar un servicio externo el primer día ya están ahí.
• Un panel de administración y una API tipo REST. Una interfaz web para definir colecciones, editar registros e inspeccionar datos, sobre una API HTTP que envuelven los SDK oficiales. El SDK de JavaScript cubre navegadores, Node.js y React Native; hay un SDK de Dart para Flutter y escritorio.
• Un solo ejecutable portátil. Los binarios precompilados usan un controlador de SQLite escrito en Go puro y se compilan con CGO desactivado, así que se compilan de forma cruzada a una lista publicada de destinos Linux, macOS, Windows, FreeBSD, OpenBSD y NetBSD. Desplegar es copiar un archivo y ejecutarlo.

Dos formas de usarlo, y la elección importa más adelante

La primera es como aplicación independiente. Descargas la versión para tu plataforma, la extraes, lanzas el comando serve y ya está. Los ejecutables precompilados llevan además una máquina virtual de JavaScript, así que puedes añadir hooks y endpoints propios en JavaScript sin tocar Go ni recompilar nada. Este es el camino que pone un prototipo delante de alguien esta misma tarde, y quedarse aquí es perfectamente razonable.

La segunda es como librería de Go. Importas PocketBase en un programa tuyo, registras rutas y lógica de negocio contra sus eventos de ciclo de vida, y compilas el resultado — tu código y el backend entero — en un único ejecutable enlazado estáticamente. El ejemplo mínimo del propio README ocupa unas quince líneas. La razón para saber esto desde el primer día es que es la salida de emergencia: la aplicación independiente no se convierte en un muro cuando tu lógica supera lo configurable, porque el mismo proyecto es también el framework que hay debajo. Los requisitos son modestos, actualmente Go 1.27 o superior para compilar.

Dónde encaja en la pila de crecimiento de un fundador

PocketBase es una herramienta de construcción, no de crecimiento, así que su aportación al crecimiento es indirecta y conviene nombrarla con honestidad: elimina las semanas que van de tener una idea a tener algo en lo que un desconocido pueda iniciar sesión. Eso importa porque casi nada de lo que se puede aprender sobre la demanda está disponible antes de ese punto. Lo que no hace es traer a nadie a lo que has construido.

• Para una primera versión que funcione. Autenticación, almacenamiento y base de datos en una sola descarga es la ruta honesta más corta de un prototipo a algo delante de lo que puedes poner un login real. Si estás haciendo el front con herramientas de IA, cuál es la mejor forma de promocionar una app hecha con vibe coding recoge el testigo donde acaba la construcción.
• Para herramientas internas que no quieres pagar. Una lista de espera, un calendario de contenidos, un seguimiento de contactos, un CRM ligero para tus primeras cincuenta conversaciones. Las colecciones más el panel de administración cubren una cantidad sorprendente de esto sin convertirse en un producto que haya que mantener.
• Al lado de la capa de crecimiento, no en su lugar. Nada de esto escribe tu posicionamiento, publica nada ni responde a un cliente. Cuando el producto existe, el trabajo cambia de forma por completo: cómo consigo mis primeros 100 usuarios es el siguiente problema, y es más difícil.
• Ten claro qué estás adoptando. Tiene licencia MIT y el README permite explícitamente el uso comercial, incluido vender un servicio construido sobre él. También está antes de la versión 1.0 y se esperan cambios incompatibles, y el repositorio tiene las pull requests restringidas temporalmente a colaboradores existentes por una oleada de envíos automatizados de baja calidad, así que cuenta con abrir incidencias en vez de parches.

Lo que aprendimos usando SQLite en producción

Aquí no somos neutrales, y esa es la parte útil: AgentCeres también usa SQLite en producción, así que lo que sigue es una decisión que tomamos, no una reseña desde fuera. Lo más importante que cambia un backend de un solo archivo es que dónde vive ese archivo pasa a ser toda tu arquitectura. El nuestro estaba en un volumen montado, y el fallo con el que nos topábamos una y otra vez era que cualquier cosa que un contenedor hubiera escrito y que nadie hubiera enviado a un almacenamiento duradero simplemente no sobrevivía al siguiente despliegue. Tampoco se anunciaba como un error: se presentaba como una aplicación que había olvidado algo en silencio, que es la peor forma posible de que llegue una pérdida de datos.

La segunda sorpresa fue que el recurso escaso era el volumen en sí, no el espacio en disco. Nuestro proveedor limita el número de volúmenes por proyecto, y llegamos a ese techo mucho antes que a cualquier límite de capacidad, lo que acabó forzando una reestructuración: los contenedores pasaron a ser desechables y el estado duradero se mudó a una base de datos más almacenamiento de objetos que les sobreviven. Si vas a tener un PocketBase para un producto, esto no te tocará nunca. Si te descubres queriendo uno por cliente, cuenta los volúmenes antes de diseñar alrededor de ellos.

La tercera es específica de SQLite y nos costó una tarde genuinamente confusa. El tipado de SQLite es flexible: teníamos marcas de tiempo guardadas como enteros en unas columnas y como texto en otras, y las comparaciones entre esas dos formas no devuelven ningún error, solo las filas equivocadas, en silencio, en una consulta que se lee correctamente. PocketBase gestiona su propio esquema, así que estás bastante protegido de esto hasta que empiezas a escribir tus propias consultas o tus propias extensiones en Go contra el mismo archivo, momento en el que pasa a ser tuyo. Decide una vez tu formato de almacenamiento y comprueba el tipo de la columna antes de fiarte de una comparación.