Pocketbase: Open-source back end in one file
pocketbase.io
pocketbase.io
- It's super easy to host. I was initially thinking of using Appwrite or Supabase but found it a tricky to self-host them, especially Supabase. I could spin up Appwrite quickly via CapRover, but found it an overkill for what I needed.
- View collections [1] make it easy to return just a subset of the data that you need. In my case I'm using a view collection as a join for users and paid_users collections, where I just return their paid through date.
- The fact that you can extend it with Go or JS [2] should make it possible to completely skip having a backend, at least if your needs aren't very complex.
I definitely plan to continue using it for some smaller/side projects. Currently I'm thinking of trying to use it as CMS for an Astro blog and in the future as backend for some browser extensions.
[1] - https://pocketbase.io/docs/collections/#view-collection
For many projects (especially hobby projects where downtime is tolerable), the former is probably quite sufficient.
I'm exceptionally happy with it. I'm developing an webapp for a friend's company and wanted a very simple system to hand-off. The whole thing is running with one binary: Pocketbase. It runs a webserver, server-side Javascript (compiled TypeScript) code, and SQLite database. The single process is hosted on Vultr for $12 per month. My frontend is written in SvelteKit (static adapter) + Svelte + TypeScript.
Pocketbase is well done. The author has been exceptionally responsive to my questions. He is fast and clear.
I have had a few minor issues: The documentation has bare spots (but is very good for most things). I had to write my own CSV loader. (I hope to open-source it.) Writing lots of objects through the CRUD interface is slow. (It's possible to write faster using server-side code.) Unit testing for the server-side JavaScript had to be shoehorned in. And I wish Copilot/ChatGPT could answer questions better. But these issues have been minor, given all my work on the project.
It has some quirks. There's no way to set the 404 page on the webserver. And the binary's location in the filesystem matters. It was designed for the author's use and you have to live with these choices.
As I said, I've been happy using it. It fit my needs exactly: simple and I could code everything in one language, TypeScript. Pocketbase is not high-performance, but I didn't need that. I've had a few ideas for side projects and, when I'm done this work, I'll implement one on Pocketbase because it is that easy.
And, as part of my contract, my friend's company will donate to Pocketbase. :)
What a positive way to give back! Kudos!
The development philosophy is on point. It's genuinely pleasant, pragmatic software which serves a real purpose and it improves weekly without feature creep.
I watch the discussions and issues slowly getting more tiresome as it becomes more mainstream and worry that he'll burn out trying to keep up with the level of support he's offered until now.
I would very strongly encourage anyone using this to generate income to support the project on open collective.
This logic could have been put within pocketbase as well, but the body of work they depend on was already .net.
Other than that it's just little JavaScript callbacks in the back and typescript in the front.
There isn't much missing that you truly need to bolt things on for, provided SQLite is appropriate for your usecase.
After they introduced Javascript support in the backend - I feel it became a serious contender to challenge Remix, Next.js etc. frameworks.
Looking forward to v1
I was shocked at how easy it was to write the query even inserting URL parameters and selecting based on the authenticated user only.
Fully recommend for basically everything. Great app. Not sure it would replace Next or Remix, but definitely add to the stack to simplify.
I'm curious to know what kind of projects did you build using PB and how was your development experience?
Development experience was outstanding. I primarily use SvelteKit and integrate PocketBase for SSR, so I use the SDK almost exclusively and it’s fantastic. Everything just works exactly the way you would expect.
I can’t imagine anything easier to implement, and as yet, I haven’t found any major gaps in what I can do with it, normally with OOB functionality.
Development velocity is very high and the developer is super responsive on GitHub. The documentation is very good and kept up to date pretty well.
My only real concern is that the project has a pretty poor bus factor, otherwise, I’m very impressed.
Sounds refreshing.
Looks like a single executable, the admin interface and the database I can store on my laptop (and add it to my backup) is all I was looking for. Thank you for PocketBase and thank you for sharing it.
That's why I always come back to HN :-)
* Something like row-level access control, so that people can only access the data in tables that belong to them (say clients can only view their own purchases, and also not modify them after they checked them out).
* Integration with the rest of the world, e.g. sending email, acting on triggers, etc.
* Something like CSV export/import.
* Internationalization.
Would that all be possible? Straightforward? Do those all require extending (with go or js)?
Looks like a nice tool.
API Rules https://pocketbase.io/docs/api-rules-and-filters/#api-rules
Hooks https://pocketbase.io/docs/js-overview/
Admin panel has backups for data, and import/export of collections schema
Most of the remainder requires extension other than authz emails, but extension at its simplest just means adding a plain old JavaScript function to run on a record lifecycle event of some kind - typically [before/after] [insert/update/delete] of <record>. Various GO APIs are exposed to the JavaScript runtime for doing filesystem, cryptography, http, email, etc work.
For i18n you have templates and a database.
As someone else mentioned, API rules can control access to rows.
It can send emails. Set timers. And send its own requests to other webservers. (I haven't used any of these features.) https://pocketbase.io/docs/js-sending-emails/
I had to write my own CSV importer. (I'm hoping to open-source it.)
As for internationalization, what specific features did you want? That seems more like a front-end feature.
https://github.com/fayazara/pocketbase-nuxt
Example has 1. Auth 2. Route rules 3. CRUD actions 4. Realtime events 5. Storage
Needs refactoring but I really enjoyed working with it, I want to add stripe subscriptions to this taking routes rules to it's limits, not sure how yet, will figure it out.
It’s just… right there :)
It plus SvelteKit has been a dream to get up and running using the JS SDK.
For CRUD apps, sveltekits progressive enhancement and form actions make it quick to to add simple function to the page. You can store the pocketbase instance, pb, in locals and reference it all over the application.
For more multiplayer things, sticking a client-side subscription to a collection allows updates of elements that can be worked with/added/moved around etc.
To keep this simple, I'm thinking exporting just the necessary data from each db and inserting that to a stats db (having a source column to each table, referring to the original db). Then load the stats db with Metabase or something.
Migrations on the stats db may be a bit of a pain, as well as making sure that all data is exported and imported correctly every time.
I'm sure there are better ideas.
Need to spend some more time looking into these go based frameworks, they seem great for quick prototyping
Where does it come from?
Why is it useful here?
What are the alternatives? Advantages/Drawbacks?
Is there an article somewhere, outside of the Pocketbase docs, presenting that pattern?
- https://github.com/pocketbase/pocketbase/blob/master/core/ap...
- https://github.com/pocketbase/pocketbase/tree/master/tools/h...
type Handler[T any] func(e T) error
type handlerPair[T any] struct {
id string
handler Handler[T]
}
type Hook[T any] struct {
mux sync.RWMutex
handlers []*handlerPair[T]
}
[1]: https://en.wikipedia.org/wiki/Event-driven_programming
[2]: https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_patt...
I am building something similar but at a lower level and based on PostgreSQL.
https://github.com/sted/smoothdb
It aims to be compatible with the PostgREST API.
"It also exposes app.Dao().DB() builder that allows executing various SQL statements (including raw queries)."
JavaScript API: https://pocketbase.io/docs/js-database/ Go API: https://pocketbase.io/docs/go-database/
Really nice, looks like something I'd love to work with someday!
More importantly, it provides a JSON API (and a client library) for interacting with those collections.
Given that it's based on SQLite I'd be very interested to know how well this would work as a true backend for a multiuser site that allows users to interact/post/etc.
Aren't there entire classes of problems that shouldn't exist for SQLite because it's intended to be an embedded database, as opposed to a client/server architecture like Postgres/Supabase?
And as such, I'm confused why this exists.
That’s the web server created by the SQLite team and also serves sqlite.org
Beyond the standalone server mode, I'm able to literally import this as a library/framework right into my Go app (https://pocketbase.io/docs/go-overview/). Having a single binary that contains my custom business logic + a very nice DB/Auth/Admin/... is a very compelling option.
The idea is to create a website for my mother, without having to deal with hosting at all (static github pages).
Does this combination work that way?
It is simple, so its single program is (1) a webserver, (2) runs server-side code, and (3) hosts a DB. I'm running a $12-per-month server on Vultr and its only service is PocketBase.
You don't need to host the webpages on PocketBase. If you wanted all your webpages to be on Github Pages, you could do that.
See my explanation on my reply to the original post.
Some static site generators have good support for generating pages from a dynamic source, say API, database or anything you can access using programming language.
See eleventy, for instance, has the “Javascript data files” [1], it run some JS code to generate a list of posts, here we can fetch from pocketbase, then, we can generate pages dynamically [2].
Pocketbase in this case just act as a lightweight CMS.
Is this what you’re talking about?
Or is it actually the backend, e.g. the frontend (browser) talks to it directly?
However if you want to write more logic you can also import Pocketbase as a library and extend it with hooks, custom endpoints etc. all written in Go.
Edit: Added more info about using Pocketbase with a JS SPA frontend.
The simplicity is simply mind boggling!
Going to give it a try!
When I moved to multiple pages, I had to use SvelteKit, which is complicated and not well documented.
- htmx (https://htmx.org/)
- Alpine.js (https://alpinejs.dev/)
both are minimal and very easy to get started.
Alpine is for example, I want to show/hide a menu on mobile. I want to upload files via drag and drop. I want to have a bin icon over an image when I hover with mouse to delete it. I want to double click an input field to edit it. I want to close an overlay when I click outside of it, or when I press “esc”.
Also modals, although you can do them in htmx very nicely too, so that’s borderline.
Anything that involves network, htmx. Things that are just frontend, Alpine suits better.
_hyperscript is basically the Alpine equivalent.
It's like the difference between Turbo and Stimulus in the Rails world
[1]: https://vanjs.org/
BUT, if you need a multi-page webapp, SvelteKit is complicated and not well documented.
As a bonus, the same file runs on basically any OS without any dependencies on the local system, not even libc.
Redbean doesn't have authentication or the client SDKs at least.
wget https://cosmo.zip/pub/cosmos/bin/redbean
chmod +x redbean
./redbean
You could replicate PocketBase in Readbean, but you would have to implement from scratch: - resources with CRUD API and real time subscriptions - admin UI - authz & authn system
Redbean requires you to write server code; Pocketbase does not. Redbean does not offer a realtime database, authentication, an admin dashboard, integrated file storage, or an inbuilt API.
I like Redbean, but it's in a completely different "market sector". It's like comparing a kit car to a luxury car: yes, they both technically serve the same purpose, but one requires much less assembly and offers a much more usable experience out of the box.
> It's like comparing a kit car to a luxury car
If all I need is a bicycle, a kit car is already over the top but will do. A luxury car makes no sense. You're thinking like everyone has the same needs that you have or something.
When Pocketbase is talking about a backend, they're talking about something like Firebase, which is a complete backend-as-a-service that implements everything you need for a service where the majority of the logic is in the frontend; it's meant to involve as little backend engineering as possible.
You're referring to the more general, standard sense of the word "backend". I agree with the sibling comment that you're not necessarily wrong in offering Redbean as a point of comparison, but the target user of Pocketbase has limited overlap with the targeted user of Redbean; the people looking for a Firebase-like solution would not be served by Redbean, and your initial post could be read as suggesting that they could be.
I do think the use of the word "backend" here is unfortunate, because it's really referring to something much more specific than the conventional use of the term.
I think you would have gotten a more positive reaction if you said something like "As an alternative take on the idea of an "open-source backend in one file, redbean is a much simpler, vastly lighter one-file web server + sqlite DB: https://redbean.dev/" to make redbean isn't necessarily intended to be the same type of "open-source backend in one file"
Anyway, redbean does look really neat even if it's not necessarily totally interchangeable with pocketbase
Personally, I think the website is clear and concise. Doesn't even have any marketing filler which is a huge plus in my corner.
Thus, if you want to write a simple website that needs permissions, storage, and server-side code, it's a great backend solution. The limitation is that it isn't high performance.
Cons: - you need to take care of all the hosting, backups, etc - cant scale to infinity like firebase (but on the other hand when you reach that scale youe firebase bill will be huge anyway)
Having the auth, db and file server in the same service.. an attacker doesn't even need lateral traversal or privilege escalation once inside..
Also as already mentioned by others there exist web APIs.