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?
(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.
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.
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 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.
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.
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.
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.
