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.
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.
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.
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.
Trailbase is the same concept, but written in Rust instead of Go.
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 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.
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/)
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.
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.
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.
Is this some sort of supabase but with sqlite and without the operational complexity?
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 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.
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)
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.
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).
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.
> 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?
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'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!
Had I known this I would not have built my own solution
I see Pocketbase, I upvote!
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.
This is an amazing project, can't wait to see the 1.0
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.
The source code is structured pretty well. I really like the file abstraction that allows for both local and S3 via the interfaces.
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
using it on mobile too
https://apps.apple.com/us/app/pocketbase-mobile-pok/id674828...
I am curious to better understand the benchmarks against simple SQLite, especially under typical load. Any level of latency will be an unnecessary overhead.
I would love something similar but for frontend.
I like developing backends, but writing JavaScript is to tiring.
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?
> 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.
Been following this for some time now and it's a real delight to use. SSE subscription is really nice.
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
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?
Database, admin, auth... is this some kind of Go's Django ?
This is 100% sick. Have been use this for one year.
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?
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.
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.
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.