I can vibe code this in rust in a day most
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.
Pocketbase – open-source realtime back end in 1 file
141–150 of 211 posts
Re: Pocketbase – open-source realtime back end in 1 file
#142Re: Pocketbase – open-source realtime back end in 1 file
#143Earlier quoted context omitted.
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.
Unsure about integrating it with Pocketbase but I imagine it is reasonable to do.
Re: Pocketbase – open-source realtime back end in 1 file
#144(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?
Re: Pocketbase – open-source realtime back end in 1 file
#145Earlier quoted context omitted.
I am so confused about this message Sounds like an sqllite performance tuning issue than anything else.
check the benchmarks here https://trailbase.io/reference/benchmarks/ its clear thats a lot of overhead on top of sqlite
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.
Re: Pocketbase – open-source realtime back end in 1 file
#146Trailbase is the same concept, but written in Rust instead of Go.
Re: Pocketbase – open-source realtime back end in 1 file
#147Unless 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.
Re: Pocketbase – open-source realtime back end in 1 file
#148Re: Pocketbase – open-source realtime back end in 1 file
#149Earlier quoted context omitted.
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.…
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.
Re: Pocketbase – open-source realtime back end in 1 file
#150Calls 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?