@@ -3,92 +3,156 @@ title: PocketBase
33description : Comparing TrailBase & PocketBase.
44---
55
6- Firstly, PocketBase is amazing! It based the trail for single-executable,
7- SQLite application bases, is incredibly easy-to-use, and a polished
8- experience. Gani, the person behind it, is a mad scientist.
6+ import { Aside } from " @astrojs/starlight/components"
7+ import GettingTrailBase from " ../getting-started/_getting_trailbase.md"
98
10- At the surface-level there are a lot of similarities between PocketBase and
11- TrailBase. In this comparison, we'll dive a little deeper and have a closer
12- look at the technical as well as philosophical differences between the two .
9+ Firstly, PocketBase is amazing! It paved the way for single-executable
10+ application bases, is incredibly easy-to-use, and a polished
11+ experience. Gani, the person behind it, is a mad scientist 🙏 .
1312
14- ### Goals & Aspirations
13+ From a distance PocketBase and TrailBase are both single-executables providing
14+ almost identical feature sets: REST APIs, realtime updates, authentication, file
15+ storage, JavaScript (JS) runtimes, admin dashboard..., all on top of SQLite.
16+
17+ For the sake of this comparison, we'll dive a little deeper to have a closer
18+ look at their differences both technically and philosophically.
19+
20+ ## Goals
1521
1622TrailBase was born out of admiration for PocketBase trying to move the needle
1723in a few areas:
1824
19- - Less abstraction, embracing standards (SQL[ ^ 1 ] , JWT, UUID), and untethered access
20- to SQLite[ ^ 2 ] including features such as recursive CTEs, virtual tables
21- and vector search.
22- The goal is to not get in your way and avoid lock-in by bespoke solutions
23- making it easier adopt TrailBase either fully or as piece-meal as well as
24- getting rid of it based on your product needs.
25- - Be just as easy to self-host and be even easier to manage a fleet of
26- deployments across integration tests, development, and production by separating
27- data, configuration, and secrets.
28- - Super-powers through SQLite extensions (regex, GIS, ...) including your own [ ^ 3 ] .
29- - Be lightweight enough to rival plain SQLite performance at least for
25+ - Less abstraction and embracing standards (SQL[ ^ 1 ] , ES6 Node-like JS runtime,
26+ JWT, UUID) to not get in your way, avoid lock-in and making it easier to
27+ adopt TrailBase either fully or as piece-meal as well as getting rid of it if
28+ necessary.
29+ - Untethered access to SQLite[ ^ 2 ] including features such as recursive CTEs,
30+ virtual tables and extensions, e.g., providing vector search and geoip out of
31+ the box[ ^ 3 ] , unlocking more use-cases and standard solutions to well-known
32+ problems.
33+ - Be lightweight and fast to rival in-process SQLite performance at least for
3034 higher-level languages.
31- - Be simple and flexible enough to be an attractive alternative to plain SQLite
32- for serving ** and** data analysis use-cases.
33-
34- ### Differences
35-
36- It's worth noting that PocketBase and TrailBase have a lot in common: they are
37- both single static binaries providing CRUD plus realtime APIs, JavaScript
38- runtimes, authentication and file storage on top of SQLite.
39- That said and for the sake of this article, let's look at some of the
40- differences and extra features that PocketBase provides:
41-
42- - PocketBase can also be used as a Go framework, i.e. instead of using the
43- binary release one can build a custom binary with custom endpoints.
44- Similarly you can use Rust to do the same with TrailBase.
45-
46- Likewise, TrailBase has a few nifty tricks up its sleeve:
47-
48- - Language independent type-safety via JSON Schemas with strict typing
49- being enforced all the way down to the database level[ ^ 4 ] .
50- - TrailBase's JavaScript runtime supports full ES6, TypeScript transpilation,
51- and is built on V8 making it [ ~ 40x faster] ( /reference/benchmarks/#javascript-performance ) .
52- Supporting ES makes it easier to integrate popular JS frameworks for SSR.
53- - First-class access to all of SQLite's features and capabilities.
54- - A simple auth UI.
55- - Stateless JWT auth-tokens for simple, hermetic authentication in other
56- backends.
57- - Efficient and stable cursor-based pagination.
58- - An admin UI that "works" on small screens and mobile :)
35+ - Be just as easy to self-host with aspirations to be even easier to manage a
36+ fleet of deployments across integration tests, development, and production.
37+ We'd also like to eventually takle replication.
38+ - Be simple, flexible and portable enough to support data analysis use-cases.
39+ Imagine a self-contained data science project that ships an interactive UI
40+ with vector search and custom JS extensions alongside its data.
5941
60- ### Language & Performance
42+ ## Differences
6143
62- Another difference is that PocketBase is written in Go, while TrailBase uses
63- Rust. Beyond feelings this may matter to you when using them as a "framework"
64- or modifying the core.
44+ Beyond goals and intentions, let's look at some of the more practical differences:
45+
46+ ### Language & Performance
6547
66- In practice, both languages are speedy options with a rich ecosystem.
67- That said, Rust's lack of a runtime and lower FFI overhead should make it the
68- more performant choice.
69- Measuring we found a significant gap with TrailBase's APIs being roughly
70- [ 10x and JS runtime 40x faster] ( /reference/benchmarks/ ) .
71- This is the result of SQLite of first-class JS engines being so quick that even
72- small overheads weight heavily.
48+ PocketBase being written in Go and TrailBase in Rust may be the most instantly
49+ visible difference.
50+ Preference aside, this will likely matter more to folks who want to use
51+ either as a framework rather than the standalone binary or modifying the core.
52+
53+ In practice, both languages are solid, speedy options with rich ecosystems.
54+ Though Rust's lack of a runtime and lower FFI overhead gives it the edge in
55+ terms of performance.
56+ Measuring we found that TrailBase's APIs are roughly [ 10x faster] ( /reference/benchmarks/ ) .
57+ This may sound like a lot but is the result of SQLite itself being extremely
58+ fast meaning that even small overheads weigh heavily.
59+
60+ Independently, TrailBase choice of V8 as its JS runtime allows code to run
61+ roughly 40x faster.
62+
63+ ### Framework Use
64+
65+ Both PocketBase and TrailBase allow customization using their built-in JS
66+ runtimes. However, some users may want even more control and built their own
67+ binaries using only bits and pieces.
68+ This is what we refer to as library or framework use. For this use-case
69+ language preference and prior experience of you and your team will likely matter
70+ a lot more with PocketBase written in Go and TrailBase in Rust.
71+
72+ Framework use is something PocketBase has allowed for a long time and is really
73+ great at.
74+ TrailBase technically allows it too, but at this point it really feels more
75+ like an afterthought while we focus on the standalone experience.
76+ Expect TrailBase to improve significantly in this area.
77+
78+ ### Features
79+
80+ When we look more deeply into the seemingly identical features sets, many and
81+ constantly evolving differences are starting to surface.
82+ In lieu of enumerating them all, let's look at some examples.
83+
84+ Auth is an area where PocketBase's maturity clearly shows: while it uses
85+ simpler session-based auth, as opposed to stateless JWT auth-tokens, it
86+ supports multi-factor auth and a larger set of social OAuth providers.
87+ This is an area where TrailBase needs to improve but maybe stateless tokens is
88+ just what you're after 😅.
89+
90+ Despite being the new kid on the block, TrailBase has a few nifty tricks up its
91+ sleeve:
92+
93+ - Language independent bindings via JSON-schema with strict type-safety
94+ being enforced from the client all the way to the database[ ^ 4 ] .
95+ - A more Node-like JS runtime with full ES6 support, built-in TypeScript
96+ transpilation, and V8 performance unlocking more of the JS ecosystem and enabling
97+ [ server-side rendering (SSR)] ( https://github.com/trailbaseio/trailbase/tree/main/examples/collab-clicker-ssr )
98+ with any popular JS framework.
99+ - Untethered access to SQLite with all its features and capabilities.
100+ - A wider set of first-class client libraries beyond JS/TS and Dart, including
101+ C#, Python and Rust.
102+ - Ships with a simple pre-built auth UI to get you started. You can always
103+ graduate to your own.
104+ - Efficient and stable cursor-based pagination as opposed to ` OFFSET ` .
105+ - An admin UI that "works" on small mobile screens 😅.
106+
107+ ### Contributing & Licensing
108+
109+ Both PocketBase and TrailBase are truly open-source: they accept contributions
110+ and are distributed under [ OSI-approved] ( https://opensource.org/licenses ) licenses.
111+ PocketBase is distributed under the permissive MIT license, while TrailBase
112+ uses the OSL-3.0 copyleft license.
113+ We chose this license over more popular, similar copyleft licenses such as
114+ AGPLv3 due to its narrower definition of derivative work that only covers
115+ modifications to TrailBase itself. This is similar to GPL's classpath or LGPL's
116+ linkage exception allowing the use of TrailBase as a framework and JS runtime
117+ without inflicting licensing requirements on your original work.
118+
119+ ## Final Words
120+
121+ PocketBase is great and both PocketBase and TrailBase are constantly evolving
122+ making it hard to give clear guidance on which to pick when.
123+ If you can afford the luxury, I'd recommend to give them both a quick spin.
124+ After all they're both incredibly quick and easy to deploy.
125+
126+ In the end, if you're looking for mileage or framework use-cases you're likely
127+ better off with PocketBase.
128+ Otherwise it may be worth giving TrailBase a closer look, especially when
129+ flexibility and performance matter.
130+
131+ <Aside type = " note" title = " Getting TrailBase"
132+ <GettingTrailBase />
133+ </Aside >
73134
74135<div class = " h-[30px]"
75136
76137---
77138
78- [ ^ 1 ] : Maybe more in line with SupaBase's philosophy. We suspect that PocketBase
79- relies on schema metadata by construction requiring alterations to be
80- mediated through PocketBase APIs to stay in sync.
139+ [ ^ 1 ] :
140+ We believe that SQL a ubiquitous evergreen technology, which in of itself
141+ is already a high-level abstraction for efficient, unified cross-database
142+ access.
143+ ORMs, on the other hand, often look great in examples but many fall apart
144+ for more complex tasks. They're certainly bespoke, non-transferable
145+ knowledge, and lead to vendor lock-in.
81146
82- [ ^ 2 ] : We believe that SQL a ubiquitous evergreen technology, which in of itself
83- is already a high-level abstraction for efficient, unified cross-database
84- access.
85- Even higher-level abstractions, such as ORMs, often look nice for simple
86- examples but quickly fall flat for more complex ones. They're certainly
87- bespoke, non-transferable knowledge, and increase vendor lock-in.
147+ [ ^ 2 ] :
148+ Maybe more in line with SupaBase's philosophy. We suspect that PocketBase
149+ relies on schema metadata by construction requiring alterations to be
150+ mediated through PocketBase to keep everything in sync.
88151
89152[ ^ 3 ] :
90153 All extensions can be built into a small, standalone shared library and
91- imported by vanilla SQLite avoiding vendor lock-in.
154+ imported by vanilla SQLite to avoid vendor lock-in.
92155
93- [ ^ 4 ] : SQLite is not strictly typed by default. Instead column types merely a
94- type affinity for value conversions.
156+ [ ^ 4 ] :
157+ Note that SQLite is not strictly typed by default. Instead column types
158+ merely a type affinity for value conversions.
0 commit comments