Agreed. Loved this FAQ notice:
"If you don't have the time to at least skim through the documentation and you plan to solely rely on some AI tool, then please do NOT use PocketBase!"
OpenAI models are a little less likely to trip up as long as you keep reminding it that it needs to account for v0.23+
It is a very good piece of work, and extensible with JS (I just tried that). I have a fear about the future because the dev is alone, and responds alone in the discussions. He is also quite, how to say, "rough" in the interactions, which I can completely understand, being the one pulled around by everyone.
This is a very, very good piece of work when you need to decorrelate the back from the front
I didn't know it was just one maintainer. That can both be a good thing for keeping the product focused, but it is also worrying, as that's a single point of failure. Anything could happen and then the whole project might fall into disrepair.
That factor alone would make me weary of overly relying on Pocketbase. I would hope that if he runs out of time, the project could be handed over to the community, but often the problem is then that we end up with 50 forks, all at different stages of development. I wonder what the best solution to this issue is.
What you are saying about forks is very true. Some very good ideas were started, then semi-abandonned on the way and they ended up with incompatible forks, and finally all of this collapsed.
I have no idea what the correct model could be.
- User signups and auth
- Stripe subscriptions using different subscription levels
- Business listings with image galleries, editable images
- Map with markers for business locations, tags, filterable business categories & tags
I'd say that the way Pocketbase handles collections, you probably don't want data that is too nested (even though there's a JSON type field, which then allows much deeper nesting).
If you're coming from Firebase, you might be used to infinitely nestable collections, but that's not how it works in Pocketbase. So you could either have a ton of collections or use nested data.
But, if for example, you had multiple clients which then need to hold a bunch of nested data, you couldn't have a 'clients' collections which then holds a bunch of collections within it. It's just one level of 'collections' within which each item then has fields.
This works well at medium complexity, but could get complicated if you had, say, a CMS where you'd want a few levels of nesting.
Unless you are actively hitting WAL contention limits (which is surprisingly hard to do on modern NVMe), the operational simplicity of a single binary beats the "scalability" of a distributed mess any day.
We’ve normalized a complexity tax where every side project "needs" a dedicated DB cluster and a Redis cache. Pocketbase proves that for 99% of CRUD apps, the bottleneck isn't the database—it's the network latency and the developer's time spent managing k8s manifests.
Supabase uses Postgres. I don't see a strong reason to prefer Pocketbase to Supabase for commercial applications. Supabase has a generous free tier and you can scale or self-host.
Premature optimization final boss.
The ones who warn about it are often the ones who don't care about architecture and just plug stuff together.
Then just convert to dollars with a decimal place when needing to display, etc.
I recall this being pretty normal regardless of what database you use.
If you find yourself caring about data types or actually writing a query, you should probably setup an actual database server.
Ah, and Pocketbase has automatic database migrations, so all schema modifications can go into version control.
I even hacked a Gemini protocol server into it, so that I can browse my personal knowledge graph using Lagrange.
I’m guessing that’s what they refer to.
Yes, you can always build a better backend yourself if you know what you're doing, or you can go from zero to having a proper auth (username/password, 0auth providers, one-time emails, multi-factor) to plug into by running a binary.
Unlike Firebase, you can run it anywhere. Unlike Supabase, you don't need 10+ containers to do so.
It might not fit your use case, which is fine, but there are a lot of use cases it does fit, and my original point was that it’s more than you might think.
I wouldn’t really describe it as niche and limiting though, that sounds quite dismissive of what is actually a pretty impressive piece of software.
Having worked for many years on Django projects, Pocketbase seems like a perfect fit for those small to medium sized projects for which you don't want to create and maintain a traditional backend for.
Happy to answer any questions.
Unsure about integrating it with Pocketbase but I imagine it is reasonable to do.
Therefore if it was me, I would use the Admin UI to create a new db with a similar data structure, and then use a third-party tool to select data and insert into the new database.
Wondering if anyone else has had a similar experience?
> If you don't have the time to at least skim through the documentation and you plan to solely rely on some AI tool, then please do NOT use PocketBase!
It's a niche little product that's alpha-level quality and changes frequently, I don't know why you would expect LLMs to be good at it.
I think the trend will shift in the opposite direction with advancement of all the genAI tools.
On a personal level, my reading time has reduced. Unless I know/respect the author, I don't bother reading genAI slop.
Pocketbase has a sense of quality/care around it that seems missing.
I'm a bit surprised on the mobile comment, since last I checked PB's UI wasn't responsive, i.e. you had to scroll a lot horizontally on mobile. Despite it's missing polish, I tried to make TB's at least work well on mobile. Could you elaborate? - thanks
The part that prompted my comment was clicking to edit a row on mobile in vertical orientation. Rather than fill the screen the edit shows up in a modal which doesn't really make sense, since you have so little horizontal space to work with. And the inputs are cut off slightly due to no padding.
And the whole admin UI overfills my (pro max) iPhone when held vertically, I think due to the navbar icons? Anyway, it'd be nice to not have to horizontally scroll to see those 40px or w/e everywhere. It makes it so you have to horizontally scroll to see or evaluate every page
One other little nice thing you could do if you wanted is prefill the username/password with the demo user.
---
Very cool project, and it's cool to see how Rust benefits the performance.
https://trailbase.io/getting-started/first-ui-app/#custom-en...
The hooks are great, even relatively complex things like spinning up infrastructure is easy (https://pocketbase.io/docs/go-event-hooks/)
Sounds like an sqllite performance tuning issue than anything else.
Naively, I would expect SQLite to be able to delete tens-of-thousands (or even hundreds) of records per seconds, since it's simply appending deletions to the WAL.
I wouldn't be surprised if that's the performance issue. It seems to be used as in memory cache for all (?) collections and uses a mutex to access them, even on reads. Most (properly set up) databases are pretty good keeping things cached and with a local socket the latency is low. With this setup I'd be very careful to do my own general purpose caching. The solution here is likely very sub optimal.
I am a lowly frontend developer who got into the SQLite hype due to twitter and DHH from Rails, didn't know how bad SQLite was.
Pocketbase uses a mutex for all the data reads and writes. That means that every write will block any readers for the write duration. If you do a lot of writes this will become quite inefficient quickly. You need some kinds of locking to write data, but if badly implemented it will pretty much roll back all concurrency advantages, you pile up goroutines that just wait to do something.
A good database does go very sophisticated steps to minimize locking, essentially you should expect from a modern database that most reads are lock free. Still it helps to understand how they coordinate locking and concurrency to optimize your applications. I.e. usually you design reads to be ultra fast and do writes in healthy bulk sizes which is also still fast but will net out to have minimum lock time. Slow reads should be done read only replicas or at times there isn't any load. So sqlite isn't slow/bad at all, if you use it correct, like any other decent database.
Below the sqlite WAL mode is explained. It is magnitudes more sophisticated then what pocketbase does. Pocketbase literally negates all that by their own locking strategy. It would likely be more efficient if the just remove their cache layer and fine tune sqlite for their use case.
Also if you require a very high amount of writes, that is realtime writes, as opposed to writes that can be delayed, you pretty much enter tough terrain. You need to make very deliberate choices and pay a lot of attention to system design depending on your requirements. So if something falls over from a high amount of writes, it because it's hard.
For example I have a sqlite db in my userdir on most servers I (personally) ssh into with "things I'd like to remember" (using dnote for spaced reptition). When I make a change to that file using "dnote", sqlrsync waits until changes stop, performs the sqlite3_rsync, and Cloudflare sends a websocket message to subscribers of that file (me on other servers) to pull down updates when they can.
I'd also like to add "dead man's alarms", etc. So it's bells and whistles around an easier-to-use sqlite.org/rsync.
This is the very high level architecture: https://sqlrsync.com/help/architecture
Source code to the client which explains the code running on your system and how I use safe(r) sqlite3 APIs to copy a running database: https://github.com/sqlrsync/client
There have been a ton of releases since then. It looked like a pretty interesting project at the time. It made me want to look for a project to use it for but I never got around to it.
I'd be interested to hear from people who have been using it and how keeping up with the releases has been (compatibility / breaking changes in API, ease of migration, issues, etc).
My biggest gripe with it by far is that the web interface is not phone-optimised at all, which prevents me from quickly correcting a field or two when I'm not behind a computer. For my use case, that happens at least once a week. Another gripe I have is that the search bar in the admin interface could be far more powerful than it currently is. Anything more complex than searching my records by exactly one field and I'm better off writing one-off scripts to do so than by using the web interface.
Good things: the control it gives me over which fields get exposed publicly, ability to resize images (instead of slowing down my build by doing so from the frontend), overall stability (never had it go down unexpectedly), S3-compatible storage, automated backups.
To give some sense of scale, ~10k records scattered across 30 or so tables (or collections as they call it), most with some attachments, and plenty of one-to-one and one-to-many relations between the tables. The database itself is only a couple of megabytes in size, but the whole backup (attachments included) is nearing 3 gigabytes now.
While updates happen pretty frequently, they don't change the parts I actually use, so I can't say I ever struggled with keeping up to date.
I use Go so all I have to do is `go get -u` and `go mod tidy` and then it's upgraded. It works great.
some things that still need to be done before v1 launch:
- easy data migration in and out (right now is a pain if its large volume of data from other DB eg firebase or sqlite!)
- API/programmatic setup of tables (right now its only via UI making it hard to setup large complex tables with variable permissions)
- Multi-instance: easiest is to have another pocketbase in "mirror" mode that it updates once a day or whatever with primary (primary > secondary method like in mongo is a great mechanism, with some kind of voting for primary)
Also, you can do programmatic setup of tables with migrations: https://pocketbase.io/docs/go-migrations/ (also available in JS). I can't remember if pocketbase will automatically write migrations to disk for you or if there's a flag you need to turn on, but you can generate those migrations on a local instance, commit them to VCS, deploy them somewhere, and either run a command to run the migrations or turn on auto-migrate (which does what you'd expect).
https://pocketbase.io/docs/going-to-production/#enable-setti...
https://github.com/pocketbase/pocketbase/blob/90d896e1cc49e3...
The developer doesn't consider this a security issue. I hope they reconsider. Non-standard cryptography is a minefield.
But a lot of user (including me) use pb as database layer only, not as backend. I still write my backend on my project and pb is just like database as a service for me. And much happier than using it as only backend.
I have around 5 instances of pocketbase running on a 10 USD/month Hetzner server, serving thousands of users a day without breaking a sweat.
I am not sure I understand—is this a wrapper around SQLite?
There's a number of competitors: Firebase, Supabase, Pocketbase, TrailBase, InstantDB, Fusio, Nhost.
I'm a control freak and I like well defined endpoints with well defined performance characteristics, so the expressiveness of the API is in my mind a drawback for anything public facing, but it's undeniably a great experience on the front end, and if you design your tables with the API and filters in mind you can get to a good place.
Overposting is another thing to be aware of when the db is so ergonomically shaped to the front end
If anyone has already done this and can share their experience, I would love to hear about it!
It works, though if you need auth/authz you'll probably want to add some middleware to get a cookie flow working instead of the jwt approach PB uses by default.
If I remember right, essentially you set the cookie on login and on auth refresh and pull it out and into the auth header on all incoming requests.
https://apps.apple.com/us/app/pocketbase-mobile-pok/id674828...
If you're comparing in-process SQLite to talking to SQLite over HTTP you'll probably get a small penalty for any language. When co-located on the same machine, you can probably expect something like ~5ms for JS (just for the event-loop to do the IO and getting back to you).
However, if you have multiple processes reading and writing from the same DB it may actually aid latency due to congestion.
I ran some benchmarks (TrailBase author here and big fan of PocketBase): https://trailbase.io/reference/benchmarks#insertion-benchmar..., where you can see, e.g. the single-process drizzle (i.e. JS with in-process SQLite) performance vs over-HTTP for TrailBase. PocketBase should be similar when not fully loaded. There's also some concrete latency percentile numbers when at full-tilt: https://trailbase.io/reference/benchmarks#read-and-write-lat.... On my machine you can expect p50 to be around 15-20ms.
Calls itself an "open source backend". A backend for what? Where does it fits in my application architecture? If it's a backend, can I write business rules in it? Is it a framework?
Personally I’d describe it as an alternative to firebase, if you’re familiar with that.
Realtime database Authentication File storage Admin dashboard
Ultimately I discovered all the cloudflare primitives soon after (eg durable objects etc), the ease, price and performance are just absurd, it feels like cheating.
From looking at the description it sounds more like subscriptions to events of data changes that are dispatched close to the data operation
How would realtime even work for a networked system going over tcp?
> A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed. Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline:
> Hard – missing a deadline is a total system failure.
> Firm – infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.
> Soft – the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.
From what I can tell, https://pocketbase.io/ attempts to be a soft-realtime system.
To me, It looks like there are just best effort events with literally no constraints or handling for delays etc
And again, I didn't see how you'd even implement such without being on both sides of the networked connection
I guess I just have to accept that the term has lost it's meaning at this point and can be used for whatever whoever wants to use it for
It's maybe more like you point out: realtime in the OS context vs realtime in an event processing context. The latter is certainly not defined as strictly and often just means push-based. It has been a popular moniker, e.g. in kafka-land, for a while. I'm not sure it intrinsically takes away from the OS context - it doesn't need to be a deep dish pizza situation.
This software is supposedly soft real-time, similar to what you'd expect from e.g. an Erlang system. Delayed tasks aren't considered fatal failures but overall you get a user experience close to what hard real-time systems are supposed to deliver.
Your average RT software has an average of 10 to 30 ms delay between operations. Performs tasks in the order of nanoseconds.
(No shade on compose / helm but have never had a 3rd party compose / helm thing that didn't poop the bed in some way after 6 months)
Is that happening here? Is there an ecosystem of other OSS self-host things built on pocketbase?
Whats special about this one?
Being a single file binary doesnt impress me; thats true of many projects in many langauges.
It seems nice you can use it as a go framework if you happen to use go, but Im not really compelled by the “it doesn't scale at all” aspects of it.
Someone whos used some other similar stuff comment on why this over any of the others, eg. self hosted superbase?
One binary to manage one sqlite file is indeed quite a selling point in comparison to this: https://github.com/supabase/supabase/blob/master/docker/dock...
Not saying Supabase is bad at all at what it does and I am very glad that it exists as an open source project, but they don't target the same type of project complexity at all.
Could you elaborate a bit more on your scaling concerns? You can certainly have lock-congestion with SQLite. That, said Postgres - while awesome - isn't the most horizontally scalable beast.
I guess for some reason I was hoping for source code that was only one file.
Kind of like people said they could write airbnb or dropbox's software in a weekend. Sure, you can approximate it, but there's a bit of soul and momentum and history there that makes it more than a repository of code and gives it a unique capacity and potential all its own.
I like developing backends, but writing JavaScript is to tiring.
You can also find dozens of drag n drop builders and block editors working for modern frontend dev, there are a lot for React for example, just vibe code the components.
I had the same instinct of using SQLite, but then, after a bit of research, PostgreSQL seemed a better alternative for serious projects.
Mostly all code is ChatGPT generated but manually tested by human.”
"Warning
Please keep in mind that PocketBase is still under active development and therefore full backward compatibility is not guaranteed before reaching v1.0.0."
Now I'm glad I didn't find out pkcketbase earlier otherwise I'd never have made Postbase.
Regarding if it will ever be ready for prime time, time will tell.