PocketBase — Dependencies#

Module info#

• Module: github.com/pocketbase/pocketbase
• Go version: 1.25.0
• Direct dependencies: 20
• Indirect dependencies (go.mod): 18 (listed explicitly in go.mod // indirect)
• Total go.sum entries: ~71 unique (module, version) pairs (143 lines / 2)

Dependency categories#

Core infrastructure#

Networking/HTTP#

Data/Storage#

Security / Auth#

JS Runtime#

Email#

Stdlib reliance#

PocketBase leans heavily on the Go standard library. The net/http package is used directly — PocketBase ships a custom HTTP router in tools/router/ built on net/http rather than adopting a third-party framework like Echo or Gin. Other heavily used stdlib packages:

• encoding/json — JSON encode/decode throughout
• net/smtp — SMTP foundation under mailyak
• crypto/... — Supplemented by golang.org/x/crypto
• database/sql — The standard DB interface (bridged to SQLite via modernc.org/sqlite)
• io/fs and embed — Used extensively to embed the Admin UI, JS type definitions, and migration SQL into the binary
• log/slog — Standard structured logger (Go 1.21+) adopted for the internal batch log handler instead of a third-party logger

The net effect is that PocketBase imports zero general-purpose third-party logging, observability, or middleware libraries. Its dependency graph is intentionally minimal.

Shared dependencies#

Compared to the broader set of 50 analyzed projects, PocketBase shares several high-frequency dependencies:

• github.com/spf13/cobra — near-universal CLI framework (also: Vault, Nomad, Helm, K3s, Dapr, …)
• golang.org/x/crypto — ubiquitous for any project handling auth (Vault, Consul, …)
• golang.org/x/net — baseline for modern Go networking
• github.com/golang-jwt/jwt/v5 — common JWT library replacing the older dgrijalva/jwt-go
• github.com/google/uuid (indirect) — UUID generation; present in most web backends

Notably absent compared to its peers: github.com/gorilla/mux, github.com/gin-gonic/gin, github.com/go-chi/chi, go.uber.org/zap, github.com/sirupsen/logrus, any ORMs.

Vendoring#

No vendor directory. PocketBase uses the standard Go module proxy and relies on go.sum checksums for reproducibility. This is typical for a project that is also distributed as a Go library — vendoring would complicate embedding by downstream users.

Notable dependency decisions#

1. modernc.org/sqlite instead of mattn/go-sqlite3: The single most consequential choice in the dependency graph. mattn/go-sqlite3 requires CGo and a C compiler, breaking cross-compilation and Docker FROM-scratch builds. modernc.org/sqlite is a transpiled pure-Go implementation that enables GOARCH=arm64 GOOS=linux go build without any host toolchain beyond the Go compiler. This is the architectural enabler of the “single portable binary” promise.

2. First-party pocketbase/dbx instead of an ORM: Rather than pulling in GORM or sqlx, the project uses its own thin query builder (pocketbase/dbx). This keeps the SQL layer predictable, avoids N+1 footguns from ORM magic, and allows the author to add PocketBase-specific features (like JSON field operators) without waiting for upstream.

3. ganigeorgiev/fexpr instead of raw SQL exposure: Exposing a custom filter DSL rather than a SQL subset prevents SQL injection by construction, and the parser is maintained by the same author — meaning PocketBase controls the entire stack from HTTP request to SQLite query.

4. dop251/goja for scripting instead of a WASM runtime or subprocess model: Embedding a JS engine in-process gives sub-millisecond hook latency with full access to the Go API surface via JS bindings, at the cost of a heavier binary. The tradeoff is explicitly chosen for developer experience — JS users get native PocketBase objects, not an RPC layer.

5. No test framework dependency: The entire test suite uses testing from the standard library only. Zero testify, zero gomock. This makes the dependency graph even leaner and demonstrates confidence in table-driven tests with stdlib assertions.