randomwebdev

> As to 4x, my concurrency levels are significantly lower which could certainly explain it.

Yes I noticed that too so that it is very likely the reason.

In all cases my initial comment wasn't intended to "dispute", argue or anything like that, so please don't feel obligated to waste time updating the benchmarks. They are valid as they are!

My initial comment was more of a note/suggestion to simply list the used versions of the tested platforms (not just for PocketBase) because often they change over time and the shown results could be misleading if someone stumble on the article 2 years later for example.

I'm sorry but that doesn't make sense to me (especially your last sentence regarding TypeScript).

During development vite has HMR and you don't need to run build after every change. This is no different when using SSR.

But I don't want to further argue. If you think that SPA is not suitable for your use case, that's ok.

I don't understand your concern with it and why this is a problem.

I haven't personally noticed the vite/esbuild memory consumption, but I also run build only once at the end before deployment or generating the prod artifacts.

Why? I think most modern bundlers and spa routers supports code splitting out of the box by just using dynamic imports, aka: `const myComponent = await import("/path/to/component")`

Currently you cannot create indexes through the admin UI, but it's in my todo.

As an alternative, you can always create indexes through DB migrations or add the index directly via the `sqlite3` cli.

The existing admin interface could be used as a very rudimentary content management, but it was really intended for quick internal data explorations and edits. Additionally, currently there are no roles for admins so permission controls within the admin area are not possible.

You could always implement your own custom CMS SPA frontend that interacts with the PocketBase API (that is how I'm planning to use it with the next version of my other open source project - Presentator).

Currently any additional data transformation is left to the developers to extend via event hooks or custom client side handling.

I've worked with CRDT in the past (yjs), but it may not be very useful in PocketBase considering that the application was designed to run on a single server and db writes are practically queued (you can have only one sqlite writer at a time). I'll investigate it further and may consider it for future release.

Yes, you can subscribe to individual records or collections.

User defined filters for the subscriptions are not supported, but it's a good idea and I may consider it in the future.

Currently the subscriptions are filtered through the collection's list and view rules - they also act as "admin level filters", aka. filters that are always applied and regular users cannot modify (getList user defined filters are only appended to the search query together with the admin defined filters).

I guess there will be differences from use case to use case, but in general migrating from PocketBase to a more common horizontal supported stack is not different from rewriting your application.

Internally, each Collection creates a standard SQLite table that holds the collection records, so migrating the data structure shouldn't be too troublesome. The only thing that may prove difficult to migrate could be reimplementing the access rules and filters.

But in my opinion, when your application reaches that level of growth requiring multiple servers and services, your business use cases mostly likely will have changed several times already from your initial idea.