I see Pocketbase, I upvote. Using it in a few production apps and it's been a very solid experience. Some breaking changes from time to time, but generally very solid.
Also has a lot of extensibility built in.
Sometimes you might hit a scenario where it doesn't provide what you need, which is when things can get a bit hairy, but nothing a skilled dev can't work around.
"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!"
I've found Gemini 2.5 pro to handle it ok. It forgets small things like using the deprecated model instead of baseModel and things like that, but nothing dramatic.
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
Ah yes, the joy of maintaining open source software. I have seen many devs burn out over the requests made of them.
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.
I have some open source I maintain, fortunately, it stays very niche so I am not overwhelmed. But I know the pain.
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.
The most substantial one is a local business directory. It's exactly the right level of medium complexity where Pocketbase shines. It's all the standard stuff:
- 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.
The "SQLite doesn't scale" argument is usually just premature optimization masquerading as architectural wisdom.
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.
That is not the case any more. The "users" show up in the shape and form of malicious AI crawling bots that don't honor your robots.txt nor apply any kind of self-throttling.
I have a personal blog set up on the cheapest digital ocean droplet and i went ahead with sqlite for it, there is not much traffic on it and i think something like sqlite is actually the best choice for such projects. I did some benchmarking with a rust cli tool, the name i don't recall right now, something like apache bench but simpler. I wouldn't have the same performance if i had mysql or postgres running on the same machine.
But you can create a dedicated DB cluster and Redis cache in AWS in 3 clicks. And then you have point in time recovery, replication, automatic failover, and guaranteed uptime. What happens when it's 3 AM and your Pocketbase server crashes?
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.
Yes, you can add an enormous amount of complexity to your app in 3 clicks. Should you? The proverbial night crashes are, in my experience, often much better problem to have than the complexity and cost of AWS.
Personally the lack of a decimal type make SQLite a no-go for me. Its too much of a hassle to do financial operations completely on the application side.
Do you only build stuff that performs financial operations? I'm not sure why sqlite being suboptimal for this one very specific use-case means that sqlite as a whole is a no-go for you.
No, not at all actually. But I had a lot of applications where at somepoint we needed to add storage of currency in the database. It became relevant for billing or other features. This without the app itself being financial in nature.
This and DATETIME. The workarounds for these are mostly fine if you’re just using SQLite as a key value store, but doing translations in SQL queries for these workarounds sounds atrocious.
90% of people aren't using "SQL" anyway. They are just doing basic CRUD operations on a data store with SQL syntax, usually abstracted through an ORM. The only reason they want a SQL database in the first place is for ACID.
If you find yourself caring about data types or actually writing a query, you should probably setup an actual database server.
Actually, with a good architecture, SQLite brings you very far. However, you need a solid architecture; otherwise, the journey ends very soon. So people with architectural wisdom can build great things with SQLite.
The ones who warn about it are often the ones who don't care about architecture and just plug stuff together.
I love it and use it for personal projects and internal tools. I tend to combine it with https://pocketpages.dev/ which gives me file-based routing and nice templates.
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.
May I know how's Pocketbase performance demand? I am thinking of hosting it on a Raspberry Pi 5 at home. Any limitations you find unusual/notable compared to standard Supabase?
I’m probably not the right person for this but it’s perfect for home use. There’s a few OSS homelab dashboards build exactly for this type of thing. I run a Home Assistant one.
So did I. I know Gemini the protocol exists, but the reality is, in almost every context "Gemini" is so much, much more likely to refer to Google's LLM that I'm taken aback when it doesn't.
They were thinking of Google Gemini, not Gemini (protocol), the latter which, although being the older, might have to consider a name change to escape a slow death after Google's hostile name-takeover.
For those unfamiliar: this is a backend server you can configure via a GUI, so you can get a working backend with little or no code. It’s great for quick prototypes, MVPs, and simple apps. The concept was popularized by Firebase.
What does it actually do? Yes, I know what a backend is - and the backends I write have hundreds to thousands of lines of code that do very specific things. How can that be eliminated? What types of applications can be built with these tools?
It's meant to be a Firebase / Supabase alternative.
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 does the same things a typical CRUD backend does (REST/realtime API, authentication, authorization, validation, etc.). For example, you could use it when building a simple todo mobile app that syncs your data in the cloud. The catch is that the moment your requirements fall outside what the system supports, you are more or less f*cked.
While that may be true, it is worth seriously checking the docs and working out what requirements you have or might have. Pocketbase does an awesome job of providing extensibility, likely most of the stuff you want that’s not fully out of the box can be added in 20 lines of code or so.
So, that sits firmly where Django/Rails are at, except that you use a GUI rather than code to define the models? I suppose that lowers the bar ever so slightly, because any management rule or business logic is still deferred to a proper framework/programming language. Seems very niche and limiting, all things considered.
I’m not quite sure what your point is, but it’s designed as a friendly but powerful GUI to quickly get a backend up and running.
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.
I've been trying out Pocketbase on a side project idea. I'm super impressed!
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.
SQLite only. I haven't come across any GIS integration. I think you should choose Pocketbase when it "not having features" and being lightweight is the feature you need.
I haven't tried this... but Pocketbase is opinionated in how it's schema is structured - and it needs to be the tool managing your schema.
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.
It's meant to build apps with. If you want to build a knowledge base, sure. But why would you build a Knowledge Base when you can use Confluence, Notion, https://www.getoutline.com/, https://clickup.com/, etc that already exist? There's free self-hosted ones too.
I’ve been using on a personal side project - but found that LLMs seem to be permanently confused over how to interact with pocketbase - to the point where I’ve even tried creating a Claude Skill to try and reduce the confusion.
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 tried to use LLMs to help me with server-side pb coding, but it was mostly a flop. LLMs don't have an up-to-date state of pb's API. 2 out of 3 times the LLM would give at least a hint how to go about something and the rest is me manually editing the code, reading the docs or looking at pb's source code. All in all, I consider it a nice "pair-programming" type of experience but one can't rely on LLMs to do the pb work for you.
This is what worked for me… clone the pb repo and stick reference to it in my agents.md. I put additional notes in my own addendum.md in the line cloned repo. ChatGPT-codex variants handle it nearly flawlessly and no issues with being out of date. I use the same pattern for all “niche” libraries
Not with Pocketbase - as I haven't found I've needed to look into the docs too much. But I have come across a whole bunch of areas LLM's seem to always answer incorrectly for. For example, ChatGPT has almost never corrected told me how to use the UI in Davinci Resolve.
I've built OpenSOHO using this, and it has been an amazing timesaver!
Even though I modified it a bit to reuse the backend. It's clearly not what it's made for, but it wasn't too hard either. If you have a look at the screenshot, you'll recognize the Pocketbase pedigree immediately.
What a respectfully and humbly written comparison page. Ditto for their Supabase comparison. I can't rate the objectivity since I know very little about TrailBase but they got my attention now. It brings me such joy to see such a writeup in a world where humility is perceived as weakness. Kudos.
I appreciate their honesty. After a quick look I’d give another point to Pocketbase for it’s admin UI. The TrailBase one is pretty sloppy (on mobile at least), and looks like it’s using bootstrap.
Pocketbase has a sense of quality/care around it that seems missing.
You won't get any argument here. PocketBase's is very polished and friendly. I fell back onto a popular pre-existing UI component system called shadcn (which does look a bit like bootstrap), not only because you gotta start somewhere but also because I'm not the caliber of UX designer Gani is :bow:. If you have the time, I would appreciate any feedback on how to improve.
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.
I started with Pocketbase but the limitation around not supporting NULLABLE columns despite being based on SQLITE was starting to become a bit of a liability, so I switched to Trailbase a little while ago.
Switching DBs is very invasive. Switching your application base even more so. As long as you're happy happy with PocketBase and there's nothing you're critically missing, the answer will almost certainly be: no. Is there anything you're looking for?
Hi! Depends on what you mean by "any JS". Many JS ecosystems depend on an environment. For example, there are browser environments where you get a common baseline with some vendor differences, there's the server where you get common baseline across nodejs, deno, bun with some differences and also proprietary APIs.
Long story short, any vanilla JS (ES5,ES6, probably even common) should be able to run. There's some standard WASI APIs to do I/O through the WASM runtime and a few TB specific APIs.
I'm a huge fan of Pocketbase. Backing up the sqlite though had me more stressed than I'd prefer, and I wanted a plug-and-play way to sqlite3_rsync a backup while Pocketbase was running: so I've been working on this: https://sqlrsync.com. MVP works. Billing isn't being checked yet (be gentle but it's Cloudflare Durable Objects underneath so it should be local, fast, and resilient.) Would love feedback from anyone open to trying it.
Love seeing the love for SQLite. Personally, I've had a great experience with litestream, which will continuously replicate any changes. Are you using https://sqlite.org/rsync.html?
Litestream is excellent however I wanted something that I could spin up faster without as much finickyneess as setting g up and securing new S3 credentials, and ideally a way to broadcast out updates.
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.
I'm aware of it but was wanted to create something that I can just quickly point at a running system and make a backup. This is a narrower use case and I accept that it's not for everyone.
There’s a high level comparison here [1] but it doesn’t go into much detail about the architecture decisions. TLDR; litestream is continuous, sqlitersync is run as a command.
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
Beware of pocketbase! I am running my startup wetarseel.ai. You'll be badly locked into one instance with one sqlite file, plus its queries are not mapping to SQL, try a bulk delete and it will choke your entire system, plus other footguns.
I'm guess but it probably depends on who's being choked here. If it's the caller, then it may be the overhead of individual deletions for each record when using the record APIs. If other users are being choked, it may refer to locking.
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've just started with go a few weeks ago, so take my info with a grain of salt.
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.
(Similar disclaimer: I'm not an expert on PocketBase implementation details)
I don't think the referenced `Store` is used in the SQLite access path and PocketBase uses SQLite in WAL mode. Besides, in cases where the `Store` is used, it uses a read/write lock to allow for concurrent reads.
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).
Been using it for about a year now, but not in a way it's "intended to be". I wrote some scripts that add data to it and then I have a (static) website that pulls data from it and builds pages. So, for me it's more of a REST API and a web interface in front of sqlite than a proper auth provider (at least for now).
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've been using it for a while. There was only one release that required manual migrations. I think 0.23.0 and apparently the dev is backporting security updates for those who haven't upgraded.
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.
I would like to try this. I have tried sqlite and duckdb, both got me started really quickly for an MVP, but then I quickly wished I had MVP’d with supabase because the step of backing up and productionizing was a lot of walking backwards. Maybe just me.
I can mirror everyone singing praise to pocketbase here. Once you grasp the concepts (which map pretty closely to SQL concepts, with rules for row-based security), it is by far the easiest way IMO to create a maintainable, robust backend with direct auth integrations and a pleasant interface.
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.
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)
There was somebody who was using one of the various sqlite replication tools to do multi-instance pocketbase. I can't remember if it was LiteFS or dqlite or something else, but I remember it scaling pretty well. The majority of applications aren't going to outgrow single-instance sqlite though.
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).
Whats the method to maintain a git repo of JS and unit tests? I remember a team with Firebase copy pasting code from dev to prod and between "modules" within an env and making a ton of mistakes.
I really like this project too! But i think there is some misunderstanding between pb users and creator. As far as I understand creator making it as complete backend solution and users should write all backend by extending pb.
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.
It makes SQLite a service that provides you with an authenticated data access layer via a REST API. It is not a wrapper although it does use SQLite as its database.
We use pocketbase for a lot of our internal LoB apps and it's been bulletproof. Saved us a lot of time and money.
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
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.
Self-hosted Supabase is pretty good. I don't think anyone argues with that. It didn't used to be as smooth and it's certainly hungrier with many more moving parts.
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 believe there is no contradiction with the definition from the linked article?
> 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.
> 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.
There is realtime, and there is "realtime". The other one being realtime in apps doing some sort of music thing, flight controllers etc. Then there is web "realtime" that basically only means 2sec in the past-realtime.
It's common to distinguish between hard real-time and soft real-time (and sometimes firm real-time).
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.
Different kind of real-time computing. This is referring to data updates being streamed to other subscribed clients automatically (if you choose to implement that).
Heh. I wasn't aware that there was a new definition of realtime. My 40+ year career consisted of about 20% realtime embedded firmware development. In all of my experience, 100ms is an absurdly long delay. Most RTOSs (that call themselves such) have latency measured in μs. The last serious RTOS that I wrote (MSP430, non-preemptive) had a firm requirement that any task must complete within 1ms. That one ran on a single threaded MCU clocked at 25MHz. It had a unix-like scheduler, with prioritized tasks, and I even threw in a 'top' display that showed per-task MCU usage, and load average.
Realtime in tech has a specific definition. The Wikipedia article covers it in more detail, but think about things like airplane wing control or space rocket computers needing to do things exactly when asked, or else people die.
I'll give it a try, but I'm not a fan of the SPA approach. Try using it with Templ and server-side rendering (SSR) instead of any JavaScript framework.
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.
Pocketbase is pretty cool, i discovered it few years ago by looking at the projects using goja at the time. since i moved to lua to avoid goja paradox.
I am curious to better understand the benchmarks against simple SQLite, especially under typical load. Any level of latency will be an unnecessary overhead.
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.
Opened the link, went to the live app, read the first page of documentation and still doesn't know what this is.
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?
I read their webpage instead of the first page of documentation and got a pretty good idea of what it was, perhaps their documentation is too in the weeds for the overview you’re looking for?
Personally I’d describe it as an alternative to firebase, if you’re familiar with that.
> Please keep in mind that PocketBase is still under active development and full backward compatibility is not guaranteed before reaching v1.0.0. PocketBase is NOT recommended for production critical applications yet, unless you are fine with reading the changelog and applying some manual migration steps from time to time.
I did initially like this, but I didn't really like the experience around extending it.
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.
Sandstorm (open source PaaS + app ecosystem) didn't make it but was encouraging to me at the time -- a standardized PaaS would seem to drastically reduce the lift to build and to host self-host things.
(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?
In the last years a market for "no code" software has sprawled, just etch the interface on a tables SPA, plug Okta, plug your backend or Firebase to their apis and you should be set.
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.
There are so, so many frameworks that it can be overwhelming to find a good fit, but give htmx or svelte a try, they often come up as great ways to simplify JS.
I'd steer clear of NextJS. Maybe even React, as they have become convoluted messes over time that rarely offer much benefit, unless you are on a big team and working on a huge, complex code base. Though job prospects are better for those frameworks. If you use AI in your workflow, however, due to the huge amount of public knowledge available, React and NextJS can become easier to work with. Be wary of the sometimes extreme breaking changes introduced quite suddenly however.
This gives you an entire API and GUI on top of a database that you can use to bang together a quick CRUD app. There is even a customizable API rules function that will let you e.g. make sure one users data doesn't show up for some other user. https://pocketbase.io/docs/api-rules-and-filters/
This project is so well thought out, you couldn't vibe code it in a week or a month. Genuinely, it's quite a wonderfully designed piece of software. It seems simple at a glance, but what makes it so good is almost intangible; it's a joy to use not only because of what it is, but what it isn't as well. And I really believe that's not something you can achieve with vibes in such short order.
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.
No, simple answer. Try it, link to the repo and I will tell you all the placed it failed. Vibe coding has its places. For something like pocketbase it most definitely is not ready yet.
Postbase, in contrast to PocketBase, doesn’t seem ready for primetime : ” Brand new project launched 02 Nov 2025, this is boiler plate but working! Expect heavy changes coming every few hours until stable
Mostly all code is ChatGPT generated but manually tested by human.”
Please keep in mind that PocketBase is still under active development and therefore full backward compatibility is not guaranteed before reaching v1.0.0."
I see Pocketbase, I upvote. Using it in a few production apps and it's been a very solid experience. Some breaking changes from time to time, but generally very solid. Also has a lot of extensibility built in. Sometimes you might hit a scenario where it doesn't provide what you need, which is when things can get a bit hairy, but nothing a skilled dev can't work around.
> nothing a skilled dev can't work around.
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!"
Yap, not famous enough to train AI on it
It’s getting better on Claude specifically now that training cutoffs are starting to move beyond the end of 2023.
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+
I've found Gemini 2.5 pro to handle it ok. It forgets small things like using the deprecated model instead of baseModel and things like that, but nothing dramatic.
[flagged]
"misomechanistic" today I learned a new word and now I want to forget it
That’s a nice $10 word to say that it offends AI slop-generating fee fees.
Cool
This was my exact comment, thanks.
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
Ah yes, the joy of maintaining open source software. I have seen many devs burn out over the requests made of them.
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.
I have some open source I maintain, fortunately, it stays very niche so I am not overwhelmed. But I know the pain.
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.
what sort of prod apps are you running from it? keen to learn by what other people are doing
The most substantial one is a local business directory. It's exactly the right level of medium complexity where Pocketbase shines. It's all the standard stuff:
- 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.
The "SQLite doesn't scale" argument is usually just premature optimization masquerading as architectural wisdom.
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.
The bottleneck of most applications is acquiring enough users to hit a technical bottleneck.
That is not the case any more. The "users" show up in the shape and form of malicious AI crawling bots that don't honor your robots.txt nor apply any kind of self-throttling.
The problem is HA. People don't go distributed for scale as much as they do to be HA. Scalability is just a nice side-effect of HA.
I have a personal blog set up on the cheapest digital ocean droplet and i went ahead with sqlite for it, there is not much traffic on it and i think something like sqlite is actually the best choice for such projects. I did some benchmarking with a rust cli tool, the name i don't recall right now, something like apache bench but simpler. I wouldn't have the same performance if i had mysql or postgres running on the same machine.
for a 98% read use case like blog SQLite is ideal
But you can create a dedicated DB cluster and Redis cache in AWS in 3 clicks. And then you have point in time recovery, replication, automatic failover, and guaranteed uptime. What happens when it's 3 AM and your Pocketbase server crashes?
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.
Yes, you can add an enormous amount of complexity to your app in 3 clicks. Should you? The proverbial night crashes are, in my experience, often much better problem to have than the complexity and cost of AWS.
> dedicated DB cluster and Redis cache in AWS
Premature optimization final boss.
Personally the lack of a decimal type make SQLite a no-go for me. Its too much of a hassle to do financial operations completely on the application side.
Don't many financial transactions in US dollars get stored as integers anyway? The number of pennies, in other words.
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.
A lot of times they are converted to BigInt and then stored as strings so different languages don't mess with the real value
Do you only build stuff that performs financial operations? I'm not sure why sqlite being suboptimal for this one very specific use-case means that sqlite as a whole is a no-go for you.
No, not at all actually. But I had a lot of applications where at somepoint we needed to add storage of currency in the database. It became relevant for billing or other features. This without the app itself being financial in nature.
This and DATETIME. The workarounds for these are mostly fine if you’re just using SQLite as a key value store, but doing translations in SQL queries for these workarounds sounds atrocious.
90% of people aren't using "SQL" anyway. They are just doing basic CRUD operations on a data store with SQL syntax, usually abstracted through an ORM. The only reason they want a SQL database in the first place is for ACID.
If you find yourself caring about data types or actually writing a query, you should probably setup an actual database server.
Actually, with a good architecture, SQLite brings you very far. However, you need a solid architecture; otherwise, the journey ends very soon. So people with architectural wisdom can build great things with SQLite.
The ones who warn about it are often the ones who don't care about architecture and just plug stuff together.
I love it and use it for personal projects and internal tools. I tend to combine it with https://pocketpages.dev/ which gives me file-based routing and nice templates.
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.
May I know how's Pocketbase performance demand? I am thinking of hosting it on a Raspberry Pi 5 at home. Any limitations you find unusual/notable compared to standard Supabase?
I’m probably not the right person for this but it’s perfect for home use. There’s a few OSS homelab dashboards build exactly for this type of thing. I run a Home Assistant one.
It’s a lot lighter than Postgres/supabase. I run it on a pi-5 and it works perfectly well.
What is Lagrange? I couldn’t find any project in the context of LLM or knowledge graph.
They said they hacked a Gemini server, Lagrange is a Geminispace browser.
https://github.com/skyjake/lagrange
I also somehow thought a Google Gemini MCP server.
So did I. I know Gemini the protocol exists, but the reality is, in almost every context "Gemini" is so much, much more likely to refer to Google's LLM that I'm taken aback when it doesn't.
There is a minimalist browser named Lagrange built for the Gemini protocol (a lightweight alternative to HTTP).
I’m guessing that’s what they refer to.
it's funny because no one brought up LLM including the link posted but you go "...it must be LLM related" :)
They were thinking of Google Gemini, not Gemini (protocol), the latter which, although being the older, might have to consider a name change to escape a slow death after Google's hostile name-takeover.
For those unfamiliar: this is a backend server you can configure via a GUI, so you can get a working backend with little or no code. It’s great for quick prototypes, MVPs, and simple apps. The concept was popularized by Firebase.
What does it actually do? Yes, I know what a backend is - and the backends I write have hundreds to thousands of lines of code that do very specific things. How can that be eliminated? What types of applications can be built with these tools?
It's meant to be a Firebase / Supabase alternative.
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 does the same things a typical CRUD backend does (REST/realtime API, authentication, authorization, validation, etc.). For example, you could use it when building a simple todo mobile app that syncs your data in the cloud. The catch is that the moment your requirements fall outside what the system supports, you are more or less f*cked.
While that may be true, it is worth seriously checking the docs and working out what requirements you have or might have. Pocketbase does an awesome job of providing extensibility, likely most of the stuff you want that’s not fully out of the box can be added in 20 lines of code or so.
So, that sits firmly where Django/Rails are at, except that you use a GUI rather than code to define the models? I suppose that lowers the bar ever so slightly, because any management rule or business logic is still deferred to a proper framework/programming language. Seems very niche and limiting, all things considered.
No you can setup everything (models and db migrations) with code, no need to use the gui, it's just here for "convienence" if you want it
I wouldn't group it with Django. It's a very simple but also well-done CMS. It is not as capable as something like Wagtail, Payload, or Craft.
I’m not quite sure what your point is, but it’s designed as a friendly but powerful GUI to quickly get a backend up and running.
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.
It’s niche and limiting in the same way that Supabase and Firebase are niche and limiting.
Looking at the examples on the front page it reminds me even more about Parse.
I've been trying out Pocketbase on a side project idea. I'm super impressed!
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.
Django has great GIS integration. How does Pocketbase compare here ? Also, can Pocketbase work with PostgreSQL or is it SQLite only ?
SQLite only. I haven't come across any GIS integration. I think you should choose Pocketbase when it "not having features" and being lightweight is the feature you need.
Like Postgres has PostGIS, SQLite has Spatialite. https://www.gaia-gis.it/fossil/libspatialite/index
Unsure about integrating it with Pocketbase but I imagine it is reasonable to do.
How easily can I migrate from an existing sqlite-based backend?
I haven't tried this... but Pocketbase is opinionated in how it's schema is structured - and it needs to be the tool managing your schema.
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.
is it suitable to maintain internal company KB? small size 15-20 people tech team
It's meant to build apps with. If you want to build a knowledge base, sure. But why would you build a Knowledge Base when you can use Confluence, Notion, https://www.getoutline.com/, https://clickup.com/, etc that already exist? There's free self-hosted ones too.
I’ve been using on a personal side project - but found that LLMs seem to be permanently confused over how to interact with pocketbase - to the point where I’ve even tried creating a Claude Skill to try and reduce the confusion.
Wondering if anyone else has had a similar experience?
From the top of https://pocketbase.io/faq/
> 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 tried to use LLMs to help me with server-side pb coding, but it was mostly a flop. LLMs don't have an up-to-date state of pb's API. 2 out of 3 times the LLM would give at least a hint how to go about something and the rest is me manually editing the code, reading the docs or looking at pb's source code. All in all, I consider it a nice "pair-programming" type of experience but one can't rely on LLMs to do the pb work for you.
This is what worked for me… clone the pb repo and stick reference to it in my agents.md. I put additional notes in my own addendum.md in the line cloned repo. ChatGPT-codex variants handle it nearly flawlessly and no issues with being out of date. I use the same pattern for all “niche” libraries
Not with Pocketbase - as I haven't found I've needed to look into the docs too much. But I have come across a whole bunch of areas LLM's seem to always answer incorrectly for. For example, ChatGPT has almost never corrected told me how to use the UI in Davinci Resolve.
[dead]
I've built OpenSOHO using this, and it has been an amazing timesaver! Even though I modified it a bit to reuse the backend. It's clearly not what it's made for, but it wasn't too hard either. If you have a look at the screenshot, you'll recognize the Pocketbase pedigree immediately.
https://github.com/rubenbe/opensoho/
Pocketbase is awesome. I'm using it as the auth layer for my side project (https://kavla.dev/).
The hooks are great, even relatively complex things like spinning up infrastructure is easy (https://pocketbase.io/docs/go-event-hooks/)
Trailbase is the same concept, but written in Rust instead of Go.
TrailBase has a comparison page https://trailbase.io/comparison/pocketbase/
What a respectfully and humbly written comparison page. Ditto for their Supabase comparison. I can't rate the objectivity since I know very little about TrailBase but they got my attention now. It brings me such joy to see such a writeup in a world where humility is perceived as weakness. Kudos.
Thanks! Standing on the shoulders of giants :heart:
> It brings me such joy to see such a writeup in a world where humility is perceived as weakness.
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.
Let us be happy about this without the doom and gloom about the future creeping in!
I appreciate their honesty. After a quick look I’d give another point to Pocketbase for it’s admin UI. The TrailBase one is pretty sloppy (on mobile at least), and looks like it’s using bootstrap.
Pocketbase has a sense of quality/care around it that seems missing.
You won't get any argument here. PocketBase's is very polished and friendly. I fell back onto a popular pre-existing UI component system called shadcn (which does look a bit like bootstrap), not only because you gotta start somewhere but also because I'm not the caliber of UX designer Gani is :bow:. If you have the time, I would appreciate any feedback on how to improve.
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
> 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.
Thank you! This is great feedback. Much appreciated.
fyi, shadcn can be styled/themed in any way you like!
Pocketbase's admin UI is not optimised for phones at all.
Trailbase won my heart by not leaving out curl-commands in their examples :)
I started with Pocketbase but the limitation around not supporting NULLABLE columns despite being based on SQLITE was starting to become a bit of a liability, so I switched to Trailbase a little while ago.
Ho do you find Trailbase compares? Worth the switch?
Switching DBs is very invasive. Switching your application base even more so. As long as you're happy happy with PocketBase and there's nothing you're critically missing, the answer will almost certainly be: no. Is there anything you're looking for?
Looks pretty nice! Do I understand correctly you can have it run any JS in an endpoint too? Seems you could host your whole app with this
https://trailbase.io/getting-started/first-ui-app/#custom-en...
Hi! Depends on what you mean by "any JS". Many JS ecosystems depend on an environment. For example, there are browser environments where you get a common baseline with some vendor differences, there's the server where you get common baseline across nodejs, deno, bun with some differences and also proprietary APIs. Long story short, any vanilla JS (ES5,ES6, probably even common) should be able to run. There's some standard WASI APIs to do I/O through the WASM runtime and a few TB specific APIs.
Another selling point for Pocketbase then.
I'm a huge fan of Pocketbase. Backing up the sqlite though had me more stressed than I'd prefer, and I wanted a plug-and-play way to sqlite3_rsync a backup while Pocketbase was running: so I've been working on this: https://sqlrsync.com. MVP works. Billing isn't being checked yet (be gentle but it's Cloudflare Durable Objects underneath so it should be local, fast, and resilient.) Would love feedback from anyone open to trying it.
Love seeing the love for SQLite. Personally, I've had a great experience with litestream, which will continuously replicate any changes. Are you using https://sqlite.org/rsync.html?
Litestream is excellent however I wanted something that I could spin up faster without as much finickyneess as setting g up and securing new S3 credentials, and ideally a way to broadcast out updates.
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.
Sorry if my question is misguided: did you try SQLite3's native online backup API? I would not use raw file access knowing they have that.
I'm aware of it but was wanted to create something that I can just quickly point at a running system and make a backup. This is a narrower use case and I accept that it's not for everyone.
I understand but in this case the quicker solution has potentially fatal flaws.
With time I have learned to speed-run less things because I've been bitten by the quick and dirty solution probably at least 100 times.
What are the differences between sqlrsync and litestream?
There’s a high level comparison here [1] but it doesn’t go into much detail about the architecture decisions. TLDR; litestream is continuous, sqlitersync is run as a command.
Here's the page threecheese meant to link: https://sqlrsync.com/help/alternatives
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
Thank you :) so embarrassing
Beware of pocketbase! I am running my startup wetarseel.ai. You'll be badly locked into one instance with one sqlite file, plus its queries are not mapping to SQL, try a bulk delete and it will choke your entire system, plus other footguns.
I am so confused about this message
Sounds like an sqllite performance tuning issue than anything else.
I'm guess but it probably depends on who's being choked here. If it's the caller, then it may be the overhead of individual deletions for each record when using the record APIs. If other users are being choked, it may refer to locking.
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.
check the benchmarks here https://trailbase.io/reference/benchmarks/ its clear thats a lot of overhead on top of sqlite
https://github.com/pocketbase/pocketbase/blob/master/tools/s...
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.
Thanks this is very helpful, can you please look at the code more, specially around inserts and reads why its so slow?
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.
I've just started with go a few weeks ago, so take my info with a grain of salt.
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.
https://sqlite.org/wal.html
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.
(Similar disclaimer: I'm not an expert on PocketBase implementation details)
I don't think the referenced `Store` is used in the SQLite access path and PocketBase uses SQLite in WAL mode. Besides, in cases where the `Store` is used, it uses a read/write lock to allow for concurrent reads.
This has not been my experience. I've definitely done bulk deletes and things have been fine. Are you sure the problem is pocketbase and/or sqlite?
It got some good discussion back in January, 2024: https://news.ycombinator.com/item?id=38898934
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).
Been using it for about a year now, but not in a way it's "intended to be". I wrote some scripts that add data to it and then I have a (static) website that pulls data from it and builds pages. So, for me it's more of a REST API and a web interface in front of sqlite than a proper auth provider (at least for now).
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've been using it for a while. There was only one release that required manual migrations. I think 0.23.0 and apparently the dev is backporting security updates for those who haven't upgraded.
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.
How is it in production? Does it it live up to your requirements?
Yes, I use it with an RSS reader and an email app and it works great.
I would like to try this. I have tried sqlite and duckdb, both got me started really quickly for an MVP, but then I quickly wished I had MVP’d with supabase because the step of backing up and productionizing was a lot of walking backwards. Maybe just me.
Is this some sort of supabase but with sqlite and without the operational complexity?
Yes that is what it is.
I can mirror everyone singing praise to pocketbase here. Once you grasp the concepts (which map pretty closely to SQL concepts, with rules for row-based security), it is by far the easiest way IMO to create a maintainable, robust backend with direct auth integrations and a pleasant interface.
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.
What kind of app do you use it for?
A couple of daily word games. https://squareword.org is the biggest one.
love it. been using for personal projects.
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)
There was somebody who was using one of the various sqlite replication tools to do multi-instance pocketbase. I can't remember if it was LiteFS or dqlite or something else, but I remember it scaling pretty well. The majority of applications aren't going to outgrow single-instance sqlite though.
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).
Whats the method to maintain a git repo of JS and unit tests? I remember a team with Firebase copy pasting code from dev to prod and between "modules" within an env and making a ton of mistakes.
I really like this project too! But i think there is some misunderstanding between pb users and creator. As far as I understand creator making it as complete backend solution and users should write all backend by extending pb.
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 agree but I’ve never been sure what that version of the product looks like then.
This is an amazing project, can't wait to see the 1.0
> PocketBase is an open source backend consisting of embedded database (SQLite) with realtime subscriptions
I am not sure I understand—is this a wrapper around SQLite?
It makes SQLite a service that provides you with an authenticated data access layer via a REST API. It is not a wrapper although it does use SQLite as its database.
It creates a REST API for your SQLite database with some extras.
I'd love to read the docs, but I'm still busy playing with the googly-eye-gopher on the landing page. Super cute idea.
Awesome project, but I'm not a fan of alphanumeric strings used as raw key bytes for AES:
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.
I see Pocketbase, I upvote!
We use pocketbase for a lot of our internal LoB apps and it's been bulletproof. Saved us a lot of time and money.
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
The source code is structured pretty well. I really like the file abstraction that allows for both local and S3 via the interfaces.
Hmmm… firebase clones are many and varied.
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?
Have you ever seriously looked into self-hosting Supabase?
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.
Self-hosted Supabase is pretty good. I don't think anyone argues with that. It didn't used to be as smooth and it's certainly hungrier with many more moving parts.
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.
Hmmm… firebase clones are many and varied.
Can you recommend any in particular, were I wanting to migrate a project from firebase?
The most well-known ones are probably: Supabase, AppWrite and PocketBase.
Is this really realtime?
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?
https://en.wikipedia.org/wiki/Real-time_computing
I believe there is no contradiction with the definition from the linked article?
> 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.
Really? I couldn't really see anything wrt degraded performance from my casual glance.
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
> 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.
There is realtime, and there is "realtime". The other one being realtime in apps doing some sort of music thing, flight controllers etc. Then there is web "realtime" that basically only means 2sec in the past-realtime.
It's common to distinguish between hard real-time and soft real-time (and sometimes firm real-time).
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.
Different kind of real-time computing. This is referring to data updates being streamed to other subscribed clients automatically (if you choose to implement that).
Realtime in tech is considered in timespans with short delays allowed, last time i have read about it it was like 100ms.
Heh. I wasn't aware that there was a new definition of realtime. My 40+ year career consisted of about 20% realtime embedded firmware development. In all of my experience, 100ms is an absurdly long delay. Most RTOSs (that call themselves such) have latency measured in μs. The last serious RTOS that I wrote (MSP430, non-preemptive) had a firm requirement that any task must complete within 1ms. That one ran on a single threaded MCU clocked at 25MHz. It had a unix-like scheduler, with prioritized tasks, and I even threw in a 'top' display that showed per-task MCU usage, and load average.
Yeah, and I’m using Pocketbase as my game engine and it isn’t giving me 60 frames per second either.
Well Pocketbase isnt embedded firmware.
And yet they claim to be "embedded performant."
Realtime in tech has a specific definition. The Wikipedia article covers it in more detail, but think about things like airplane wing control or space rocket computers needing to do things exactly when asked, or else people die.
Even that stuff has a delay.
FYI, my above referenced RTOS was for a space-based application.
Are you talking about (very good) webapps?
Your average RT software has an average of 10 to 30 ms delay between operations. Performs tasks in the order of nanoseconds.
Been following this for some time now and it's a real delight to use. SSE subscription is really nice.
I found the real time (SSE) very buggy, unpredictable and hard to debug.
Do you use it in small projects only?
I used to use other tools like supabase and others for side projects.
After discovering pocketbase, I never went back to any of those tools. Works surprisingly well even for mid to large web-apps.
I'll give it a try, but I'm not a fan of the SPA approach. Try using it with Templ and server-side rendering (SSR) instead of any JavaScript framework.
If anyone has already done this and can share their experience, I would love to hear about it!
I can speak to this.
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.
using it on mobile too
https://apps.apple.com/us/app/pocketbase-mobile-pok/id674828...
Wow you charge a subscription for this? The Apple ecosystem is wild.
Had I known this I would not have built my own solution
Pocketbase is pretty cool, i discovered it few years ago by looking at the projects using goja at the time. since i moved to lua to avoid goja paradox.
I am curious to better understand the benchmarks against simple SQLite, especially under typical load. Any level of latency will be an unnecessary overhead.
How do you use simple SQLite without any code in a webapp where the database is on the server?
You can't. I am curious if this adds another layer of latency.
Can easily go either way.
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.
How or why is this better than InsantDB?
Probably easier to self-host Pocketbase.
There's a number of competitors: Firebase, Supabase, Pocketbase, TrailBase, InstantDB, Fusio, Nhost.
This is 100% sick. Have been use this for one year.
Opened the link, went to the live app, read the first page of documentation and still doesn't know what this is.
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?
I read their webpage instead of the first page of documentation and got a pretty good idea of what it was, perhaps their documentation is too in the weeds for the overview you’re looking for?
Personally I’d describe it as an alternative to firebase, if you’re familiar with that.
It's the first thing on the linked page:
Realtime database Authentication File storage Admin dashboard
> Please keep in mind that PocketBase is still under active development and full backward compatibility is not guaranteed before reaching v1.0.0. PocketBase is NOT recommended for production critical applications yet, unless you are fine with reading the changelog and applying some manual migration steps from time to time.
Even for battle-tested software like Postgresql, always read the changelog and test it thoroughly before upgrading.
I did initially like this, but I didn't really like the experience around extending it.
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.
Database, admin, auth... is this some kind of Go's Django ?
It's a platform similar to Supabase, Firebase and the like. I guess Heroku is also a somewhat reasonable comparison.
Apparently 1 file just means a static go binary with a bunch of separate assets compiled in.
I guess for some reason I was hoping for source code that was only one file.
Same here. At first, I thought it was a one-file-based database, which would have been even more commendable.
That should have been possible, since it's based on SQLite.
Same
Like a single header c lib from some eastern European S tier programmer.
tsoding mentioned
I really loved his ocaml days. Learnt alot. He does only C these days, but his streams are fun to watch nontheless.
Sandstorm (open source PaaS + app ecosystem) didn't make it but was encouraging to me at the time -- a standardized PaaS would seem to drastically reduce the lift to build and to host self-host things.
(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?
Congrats on the launch!
eh? what launch? been using it for years now, it's brilliant
I would love something similar but for frontend.
I like developing backends, but writing JavaScript is to tiring.
In the last years a market for "no code" software has sprawled, just etch the interface on a tables SPA, plug Okta, plug your backend or Firebase to their apis and you should be set.
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.
There are so, so many frameworks that it can be overwhelming to find a good fit, but give htmx or svelte a try, they often come up as great ways to simplify JS. I'd steer clear of NextJS. Maybe even React, as they have become convoluted messes over time that rarely offer much benefit, unless you are on a big team and working on a huge, complex code base. Though job prospects are better for those frameworks. If you use AI in your workflow, however, due to the huge amount of public knowledge available, React and NextJS can become easier to work with. Be wary of the sometimes extreme breaking changes introduced quite suddenly however.
What facilities would an equivalent frontend solutuon have in your mind?
How's this different from... a database? Most modern dbs come with auth and some gui. I guess if you need real-time updates this is cool
This gives you an entire API and GUI on top of a database that you can use to bang together a quick CRUD app. There is even a customizable API rules function that will let you e.g. make sure one users data doesn't show up for some other user. https://pocketbase.io/docs/api-rules-and-filters/
I can vibe code this in rust in a day most
This project is so well thought out, you couldn't vibe code it in a week or a month. Genuinely, it's quite a wonderfully designed piece of software. It seems simple at a glance, but what makes it so good is almost intangible; it's a joy to use not only because of what it is, but what it isn't as well. And I really believe that's not something you can achieve with vibes in such short order.
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.
No, simple answer. Try it, link to the repo and I will tell you all the placed it failed. Vibe coding has its places. For something like pocketbase it most definitely is not ready yet.
lol
Neat. You should do a video of that and comparing the results.
Postbase uses PostgreSQL and BetterAuth. No GUI yet, but it's in the plan and will be called Admin (Panel).
I had the same instinct of using SQLite, but then, after a bit of research, PostgreSQL seemed a better alternative for serious projects.
Postbase, in contrast to PocketBase, doesn’t seem ready for primetime : ” Brand new project launched 02 Nov 2025, this is boiler plate but working! Expect heavy changes coming every few hours until stable
Mostly all code is ChatGPT generated but manually tested by human.”
So does Pocketbase
"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."
And by that description, I assume it's never going to be ready for primetime.
I made it for my own needs without knowing pocketbase existed and it solved my problems and thats all that matters.
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.
Looks very cool! Good luck!
Thank you