[HN Gopher] Pocketbase - open-source realtime back end in 1 file
___________________________________________________________________
Pocketbase - open-source realtime back end in 1 file
Author : modinfo
Score : 600 points
Date : 2025-11-28 03:45 UTC (19 hours ago)
(HTM) web link (pocketbase.io)
(TXT) w3m dump (pocketbase.io)
| mickael-kerjean wrote:
| Is this some sort of supabase but with sqlite and without the
| operational complexity?
| odie5533 wrote:
| Yes that is what it is.
| sjdonado wrote:
| This is an amazing project, can't wait to see the 1.0
| ranger_danger wrote:
| 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.
| florians wrote:
| Same
| dustbunny wrote:
| Like a single header c lib from some eastern European S tier
| programmer.
| ftchd wrote:
| tsoding mentioned
| phplovesong wrote:
| I really loved his ocaml days. Learnt alot. He does only
| C these days, but his streams are fun to watch
| nontheless.
| wowamit wrote:
| Same here. At first, I thought it was a one-file-based
| database, which would have been even more commendable.
| SpaceNoodled wrote:
| That should have been possible, since it's based on SQLite.
| EvanAnderson wrote:
| 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).
| impure wrote:
| 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.
| tommica wrote:
| How is it in production? Does it it live up to your
| requirements?
| impure wrote:
| Yes, I use it with an RSS reader and an email app and it
| works great.
| input_sh wrote:
| 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.
| wowamit wrote:
| > 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?
| RedShift1 wrote:
| It creates a REST API for your SQLite database with some
| extras.
| odie5533 wrote:
| 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.
| rubenvanwyk wrote:
| Trailbase is the same concept, but written in Rust instead of Go.
| odie5533 wrote:
| TrailBase has a comparison page
| https://trailbase.io/comparison/pocketbase/
| rudedogg wrote:
| 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.
| input_sh wrote:
| Pocketbase's admin UI is not optimised for phones _at all_.
| trailbase wrote:
| 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
| rudedogg wrote:
| > 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.
| Natfan wrote:
| fyi, shadcn can be styled/themed in any way you like!
| cyco130 wrote:
| 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.
| rahulroy wrote:
| > 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.
| jama211 wrote:
| Let us be happy about this without the doom and gloom
| about the future creeping in!
| trailbase wrote:
| Thanks! Standing on the shoulders of giants :heart:
| raybb wrote:
| 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...
| trailbase wrote:
| 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.
| elfrinjo wrote:
| Trailbase won my heart by not leaving out curl-commands in
| their examples :)
| odiroot wrote:
| Another selling point for Pocketbase then.
| vunderba wrote:
| 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.
| Humphrey wrote:
| Ho do you find Trailbase compares? Worth the switch?
| zipping1549 wrote:
| Been following this for some time now and it's a real delight to
| use. SSE subscription is really nice.
| tommica wrote:
| Do you use it in small projects only?
| ftchd wrote:
| using it on mobile too
|
| https://apps.apple.com/us/app/pocketbase-mobile-pok/id674828...
| rjh29 wrote:
| Wow you charge a subscription for this? The Apple ecosystem is
| wild.
| aitchnyu wrote:
| 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.
| ffsm8 wrote:
| 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
| zwnow wrote:
| Realtime in tech is considered in timespans with short delays
| allowed, last time i have read about it it was like 100ms.
| fragmede wrote:
| 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.
| zwnow wrote:
| Even that stuff has a delay.
| anonymousiam wrote:
| FYI, my above referenced RTOS was for a space-based
| application.
| anonymousiam wrote:
| 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 ms. 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.
| zwnow wrote:
| Well Pocketbase isnt embedded firmware.
| SpaceNoodled wrote:
| And yet they claim to be "embedded performant."
| JSR_FDED wrote:
| Yeah, and I'm using Pocketbase as my game engine and it
| isn't giving me 60 frames per second either.
| foul wrote:
| 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.
| phplovesong wrote:
| 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.
| SerCe wrote:
| 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.
| ffsm8 wrote:
| 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
| trailbase wrote:
| > 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.
| cess11 wrote:
| 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.
| m00dy wrote:
| I can vibe code this in rust in a day most
| razemio wrote:
| 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.
| m00dy wrote:
| lol
| steve_adams_86 wrote:
| 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.
| a96 wrote:
| Neat. You should do a video of that and comparing the results.
| postbase wrote:
| Congrats on the launch!
| socks wrote:
| eh? what launch? been using it for years now, it's brilliant
| wowamit wrote:
| I am curious to better understand the benchmarks against simple
| SQLite, especially under typical load. Any level of latency will
| be an unnecessary overhead.
| victorbjorklund wrote:
| How do you use simple SQLite without any code in a webapp where
| the database is on the server?
| wowamit wrote:
| You can't. I am curious if this adds another layer of
| latency.
| trailbase wrote:
| 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.
| JodieBenitez wrote:
| Database, admin, auth... is this some kind of Go's Django ?
| cess11 wrote:
| It's a platform similar to Supabase, Firebase and the like. I
| guess Heroku is also a somewhat reasonable comparison.
| Humphrey wrote:
| 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.
| JodieBenitez wrote:
| Django has great GIS integration. How does Pocketbase compare
| here ? Also, can Pocketbase work with PostgreSQL or is it
| SQLite only ?
| Humphrey wrote:
| 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.
| zeckalpha wrote:
| 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.
| jdthedisciple wrote:
| How easily can I migrate from an existing sqlite-based backend?
| Humphrey wrote:
| 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.
| parkersweb wrote:
| 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?
| Humphrey wrote:
| 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.
| input_sh wrote:
| 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.
| p2detar wrote:
| 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.
| catketch wrote:
| 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
| olalonde wrote:
| 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.
| dotancohen wrote:
| 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?
| olalonde wrote:
| 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.
| d1sxeyes wrote:
| 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.
| ezst wrote:
| 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.
| shagrath wrote:
| 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
| d1sxeyes wrote:
| 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.
| evantbyrne wrote:
| 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.
| F7F7F7 wrote:
| It's niche and limiting in the same way that Supabase and
| Firebase are niche and limiting.
| input_sh wrote:
| 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.
| tidbeck wrote:
| Looking at the examples on the front page it reminds me even
| more about Parse.
| jharohit wrote:
| 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)
| rubenbe wrote:
| 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/
| noodletheworld wrote:
| 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?
| gjvc wrote:
| _Hmmm... firebase clones are many and varied._
|
| Can you recommend any in particular, were I wanting to migrate
| a project from firebase?
| trailbase wrote:
| The most well-known ones are probably: Supabase, AppWrite and
| PocketBase.
| trailbase wrote:
| 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.
| input_sh wrote:
| 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.
| matt_callmann wrote:
| 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!
| jddj wrote:
| 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.
| aleda145 wrote:
| 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/)
| yungeeker wrote:
| This is 100% sick. Have been use this for one year.
| postbase wrote:
| 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.
| andsoitis wrote:
| 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."_
| SwiftyBug wrote:
| And by that description, I assume it's never going to be
| ready for primetime.
| postbase wrote:
| 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.
| postbase wrote:
| 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."
| jddj wrote:
| 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
| rjh29 wrote:
| > 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.
| thisgoodlife wrote:
| Even for battle-tested software like Postgresql, always read
| the changelog and test it thoroughly before upgrading.
| krzyk wrote:
| I would love something similar but for frontend.
|
| I like developing backends, but writing JavaScript is to tiring.
| throwaway77385 wrote:
| 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.
| andsoitis wrote:
| What facilities would an equivalent frontend solutuon have in
| your mind?
| foul wrote:
| 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.
| olav wrote:
| 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.
| phl wrote:
| What is Lagrange? I couldn't find any project in the context of
| LLM or knowledge graph.
| andsoitis wrote:
| 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.
| foul wrote:
| They said they hacked a Gemini server, Lagrange is a
| Geminispace browser.
|
| https://github.com/skyjake/lagrange
| stavros wrote:
| I also somehow thought a Google Gemini MCP server.
| TeMPOraL wrote:
| 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.
| throwaway290 wrote:
| it's funny because no one brought up LLM including the link
| posted but you go "...it must be LLM related" :)
| stareatgoats wrote:
| 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.
| 8cvor6j844qw_d6 wrote:
| 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?
| F7F7F7 wrote:
| 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.
| rekttrader wrote:
| It's a lot lighter than Postgres/supabase. I run it on a pi-5
| and it works perfectly well.
| 9dev wrote:
| 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.
| throwaway77385 wrote:
| 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.
| BrandoElFollito wrote:
| 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
| throwaway77385 wrote:
| 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.
| BrandoElFollito wrote:
| 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.
| tajd wrote:
| what sort of prod apps are you running from it? keen to learn
| by what other people are doing
| throwaway77385 wrote:
| 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.
| mrbluecoat wrote:
| > 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!"
| TeMPOraL wrote:
| Cool, but misomechanistic jabs are getting boring at this
| point.
| guizadillas wrote:
| "misomechanistic" today I learned a new word and now I want
| to forget it
| Bombthecat wrote:
| Yap, not famous enough to train AI on it
| F7F7F7 wrote:
| 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+
| vladstudio wrote:
| I see Pocketbase, I upvote!
| rfc2324 wrote:
| 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.
| trailbase wrote:
| 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?
| rfc2324 wrote:
| 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.
| pzmarzly wrote:
| What are the differences between sqlrsync and litestream?
| threecheese wrote:
| 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.
| rfc2324 wrote:
| 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
| pdimitar wrote:
| 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.
| rfc2324 wrote:
| 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.
| osbulbul wrote:
| 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.
| pspeter3 wrote:
| I agree but I've never been sure what that version of the
| product looks like then.
| oliwary wrote:
| 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.
| crashabr wrote:
| What kind of app do you use it for?
| icemelt8 wrote:
| 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.
| coolgoose wrote:
| I am so confused about this message
|
| Sounds like an sqllite performance tuning issue than anything
| else.
| icemelt8 wrote:
| check the benchmarks here
| https://trailbase.io/reference/benchmarks/ its clear thats a
| lot of overhead on top of sqlite
| Yokohiii wrote:
| 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.
| icemelt8 wrote:
| 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.
| trailbase wrote:
| 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.
| sktrdie wrote:
| 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
| PUSH_AX wrote:
| 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.
| ripped_britches wrote:
| 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.
| emehrkay wrote:
| The source code is structured pretty well. I really like the file
| abstraction that allows for both local and S3 via the interfaces.
| awinter-py wrote:
| 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?
| leo_e wrote:
| 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.
| 9notorp wrote:
| 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.
| jitl wrote:
| for a 98% read use case like blog SQLite is ideal
| denismenace wrote:
| 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.
| burky wrote:
| 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.
| mike_d wrote:
| 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.
| benjaminoakes wrote:
| 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.
| davidron wrote:
| The bottleneck of most applications is acquiring enough users
| to hit a technical bottleneck.
| born-jre wrote:
| 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.
| HeavyStorm wrote:
| 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?
| matt2000 wrote:
| It's the first thing on the linked page:
|
| Realtime database Authentication File storage Admin dashboard
| jama211 wrote:
| 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.
| mohas wrote:
| Had I known this I would not have built my own solution
| BoppreH wrote:
| 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.
___________________________________________________________________
(page generated 2025-11-28 23:01 UTC)