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 not sure this is expected but it didn't seem to make much of a difference with my setup

I expect it to be faster but it is also possible that maybe in your specific collection and execution scenario it somehow perform worst, or at least not the same as in my benchmarks, I'm not sure.

The ~4x mentioned speed up is based on the tests for Hetzner CAX41 with the CGO driver when creating 50k records with 500 concurrent clients:

Old (58.409064001s): https://github.com/pocketbase/benchmarks/blob/54140be5fb0102...

New (13.580098262s): https://github.com/pocketbase/benchmarks/blob/7df0466ac9bd62...

---

Edit: Based on your benchmarks repo (https://github.com/trailbaseio/trailbase-benchmark/tree/main...) note that compiling PocketBase with `CGO_ENABLED=1` is no longer enough to kick in the github.com/mattn/go-sqlite3 driver and you need to enable it manually as shown in the db_cgo.go in our benchmarks OR like in https://pocketbase.io/docs/go-overview/#github-commattngo-sq... (the reason for this change was to avoid the "multiple definition" linker errors).

(Disclaimer: I'm PocketBase author)

It is nice to see more backends utilizing SQLite. The benchmarks and the Comparisions section also seem well done.

Just a nitpick - list the versions of the tested platforms.

Based on your benchmarks repo it looks like that the tests were done against PocketBase < v0.23 but note that PocketBase v0.23+ (especially with the Create API rule dry submit removal in v0.24+) has introduced significant changes and performance improvements - ~4x times in high concurrent scenarios in our own benchmarks[0] (if you want to retest it note that the CGO driver is no longer loaded by default and will have to be registered manually; see the example "db_cgo.go" in the PocketBase benchmarks repo or in the "Custom SQLite driver" docs[1]).

[0]: https://github.com/pocketbase/benchmarks

[1]: https://pocketbase.io/docs/go-overview/#custom-sqlite-driver

Hi, PocketBase author here.

Keep in mind that PocketBase do a lot more than just executing a raw DB query. We perform data validation, normalization, serialization, enriching, auto fail-retry to handle additional SQLITE_BUSY errors, etc. All of this comes with some cost and will always have an effect when doing microbenchmarks like this.

The performance would also depend on what version of PocketBase did you try (before or after v0.10), whether you used CGO or the pure Go driver, etc.

For a benchmark closer to "real world" scenarios tested on various servers you can check the results from https://github.com/pocketbase/benchmarks.

There is definitely room for improvements (I haven't done any detailed profiling yet) but the current performance is "good enough" for the purposes the applications PocketBase is intended for (I've shared some numbers regarding a PocketBase app on production in https://github.com/pocketbase/pocketbase/discussions/4254).

Hope the above helps.

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")`

It is really a cool project. We are using it as a default driver in PocketBase and although it is not a "drop-in" replacement of the CGO alternative `mattn/go-sqlite3` (different dsn format, some differences in the error messages, etc.), with a small abstraction it works fine for most cases and greatly simplify cross compilation.

Performance wise I haven't done intensive benchmark tests yet, but from my local experiments last year it performed ~1.5-2x slower than the CGO version for some queries (it is especially noticeable with LIKE expressions on large string data), but as mentioned previously, for most use cases it is already good enough.

Here are the most recent benchmarks I could find (I think from one of the maintainers of the lib) comparing the CGO version and the pure Go port - https://docs.google.com/spreadsheets/d/1YOP1D_ZhuR-ednQhTH6S...

Its not schema free (although you can create a json field and put whatever you want in it).

You can define schema via migrations or through the admin UI (see https://pocketbase.io/docs/manage-collections/).

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.

There is already a JavaScript SDK (https://github.com/pocketbase/js-sdk) that works both in the browser and node.

Dart SDK (targeting mainly Flutter) is also on the way.

Unfortunately I'm not very uptodate with Android (Kotlin) or iOS (Swift) development and therefore community contributions are more than welcomed.

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.

Yes, built-in sounds better. I'll update it.

The documentation is not auto generated and is part of the static landing site (built with SvelteKit).

I didn't bother open source it because it is kinda messy and a little complicated to be edited by users not familiar with the codebase, but I'll try to find some time in the future and may publish it.

In the meantime, if you find typos or think that some of the wording could be improved, feel free to open an issue or discussion in the main repo and I'll fix them.

Uploaded files and your database are stored outside of the binary.

You may want to check Supabase or Nhost in that case.

PocketBase was specifically designed to be self-contained and running only on a single server.

"Collections" stores a single records table meta data (eg. name, fields, validators, etc.), so when you create a new collection a new related table will be created (see https://github.com/pocketbase/pocketbase/blob/3d07f0211dc747...).

The admin UI just shows the collections through the web api (https://pocketbase.io/docs/api-collections/).

I actually started with GORM, but its too complex and I ended up replacing it with a simpler query builder package (ozzo-dbx). While the query builder has abstraction for other databases, I'm not planning supporting them at the moment.

Hm, there is nothing preventing you to start multiple services from a single binary.

I'm not sure that PocketBase would be suitable for your use case, but it is distributed also as a Go package (see https://pocketbase.io/docs/use-as-framework/) and you could combine it with any other GUI Go package (fyne, go-astilectron, etc.)

By default PocketBase uses the local filesystem, but you could also configure a S3 compatible storage (AWS, DigitalOcean, Vultr, etc.) from "Settings > Files Storage > Use S3 storage".

I've started working on the project ~ 3-4 months ago. The last 4 weeks I've taken a longer break from my day-to-day job so that I could finalize the first release.

It's implemented in the application, it's not a feature of SQLite, but its very simple and robust - when a record is created/updated/deleted I'm broadcasting the change to all subscribers that are allowed to receive it (the access control is based on the colleciton's list and view rules).

The realtime api implementation could be found at https://github.com/pocketbase/pocketbase/blob/master/apis/re...

Go's default `net/http` package will serve HTTP2 when a https configuration is provided (also most web browsers don't support h2c, aka. HTTP2 without tls).

The default limit of ~100 connections should be more than enough for most applications (additionally, the JS SDK client maintains a single SSE connection for a page no matter to how many things the user has subscribed, so that also helps).

Other than some json functions, PocketBase doesn't use too much SQLite specific features, but I don't plan adding support for other databases at the moment.

Please also note that PocketBase is designed to be deployed only on a single server, so it cannot scale horizontally out of the box. Supabase/Nhost are better suited for that.

Yes, I'm aware of this limitation, but PocketBase uses HTTP2 when combined with the --https flag (this is by go's default net/http implementation) so it shouldn't be too much of a concern.

Thanks! It was initially created to be the backend for the next version of my other open source project - Presentator v3 (https://github.com/presentator/presentator).

You could read more at https://github.com/presentator/presentator/issues/183, but to summarize - I wanted something that could be self hosted with almost no additional setup and no dependency on 3rd party services.

PocketBase is a small open source project that I've been working for the last couple of months.

You could think of PocketBase as a lightweight Firebase/Supabase alternative.

In short, it is an open source Go backend (framework and app) consisting of:

- embedded database (SQLite) with realtime subscriptions\

- backed-in files and users management

- convenient Admin dashboard UI

- simple REST-ish API

And all of this compiles to a single portable binary.

It's still a little rough around the edges, but you could give it a try and share your feedback.