Pocketbase: Open-source back end in one file

Original Article ↗ Hacker News Discussion ↗

PocketBase, a self-hosted backend packaged as a single Go binary with SQLite, is drawing praise for its simplicity, fast developer onboarding, and ease of deployment compared to heavier alternatives like Firebase, Supabase, or Appwrite. Commenters highlight its built-in auth, real-time data, admin UI, and JS/Go extensibility as enough for many small to mid-sized apps, especially when paired with lightweight front-end tools such as SvelteKit, htmx, or Alpine.js. Concerns focus on its single-maintainer bus factor, SQLite’s scaling limits, and some missing conveniences (e.g., bulk insert, CSV import), but many report successful production use with thousands of users and low hosting costs.

Overall sentiment

  • Strongly positive thread; many report using PocketBase in production and for side projects.
  • Main attraction: simplicity, minimalism, and very fast development velocity.
  • Some concerns about scalability, “bus factor” (one main maintainer), and security model.

Use cases and developer experience

  • Used for a wide variety of apps: mobile apps, bedtime tracker, microblog, TikTok-like clone, budget app, text-to-speech tool, wine cellar tracking, CMS for blogs/static sites, and business apps with tens of thousands of customers.
  • Reports of “zero issues” in production and high satisfaction with the admin UI and JS SDK.
  • Described as “pleasant”, “pragmatic”, and “just works” once you understand its model.
  • Some friction: docs have thin spots, CSV import had to be custom-built, unit testing for server-side JS is awkward, and large CRUD batches can be slow unless handled server-side.

Deployment, architecture, and scaling

  • Single binary with embedded SQLite is heavily praised; “drop one file on a server and go.”
  • Easier to self-host than Supabase/Appwrite; runs fine on small VPSes or in containers.
  • Suitable where occasional downtime is acceptable; vertical scaling considered enough for many small/medium projects.
  • SQLite concurrency seen as adequate for “thousands of parallel users” or ~5k daily users; multi-DB analytics and multi-instance syncing are trickier and need custom approaches.

Features and extensibility

  • Provides auth, row-level access control via API rules, real-time subscriptions, file storage, web UI, and JSON/HTTP/WebSocket APIs.
  • Custom logic via Go or embedded JavaScript/TypeScript hooks (record lifecycle, timers, HTTP calls, emailing).
  • Supports raw SQL and view collections for joins, plus a migration mechanism via files in a migrations directory.
  • Lacks built-in bulk insert, CSV import/export, GraphQL, and deep customization of some server aspects (e.g., 404 page).

Comparisons and alternatives

  • Frequently compared to Firebase, Supabase, and Appwrite; positioned as a simpler, fully self-hosted “Firebase-like” backend.
  • Some argue it’s “substantially better” than Supabase for ease of hosting; others note each serves different needs.
  • Redbean and other “one-file” tools are mentioned but seen as lower-level web servers rather than full backend-as-a-service equivalents.

Front-end stacks

  • Common pairings: Svelte/SvelteKit, React+Vite, Nuxt 3, Astro, HTMX, Alpine.js, VanJS, static site generators (e.g., Eleventy).
  • Often used so that most business logic lives on the frontend, with PocketBase providing CRUD, auth, and real-time data.