English for PocketBase Developers

PocketBase is an open-source backend-as-a-service written in Go that ships as a single executable — an embedded SQLite database, a REST and realtime API, file storage, and an admin dashboard, all bundled into one binary you can run anywhere. Its appeal is largely operational: no separate database server, no complex deploy pipeline. But its vocabulary blends database terms, Go-specific concepts, and its own take on access rules. If your team is evaluating or shipping with PocketBase, here’s the English you’ll need for backend discussions.

---

Core Concepts

Collection — PocketBase’s term for a database table, defined and managed through the admin UI or an API, roughly equivalent to a “model” in other frameworks. “We added a comments collection with a relation field back to posts — no migration file to write by hand, PocketBase generated the schema change.”

Record — a single row within a collection; PocketBase auto-generates a REST API for creating, reading, updating, and deleting records. “Each new record gets a generated ID automatically — don’t try to set your own unless the field is explicitly configured to allow it.”

Single-binary deploy — the entire backend (API, database, admin UI) ships as one compiled executable with no external dependencies to install. “Deploying an update is scp the binary and restart the service — there’s no separate database migration step or container orchestration to coordinate.”

---

Realtime and Auth

Realtime subscriptions

PocketBase exposes realtime subscriptions over Server-Sent Events, letting clients get pushed updates when records in a collection change.

“We subscribed the frontend to the messages collection — new messages appear instantly without polling, since PocketBase pushes the update over the realtime connection.”

Auth rules

Auth rules are per-collection, expression-based access rules that determine who can view, create, update, or delete records — evaluated server-side per request.

“The list rule on posts is @request.auth.id != '' && published = true — logged-in users only see published posts, guests see nothing at all.”

API rules vs. auth rules

PocketBase distinguishes API rules (general access filters) from auth-specific fields like @request.auth.id, which reference the currently authenticated user making the request.

“Don’t hardcode a user ID in the rule — reference @request.auth.id so the filter applies correctly to whichever user is actually logged in.”

---

Extending the Backend

Hook — a Go (or JavaScript, via the embeddable pb_hooks engine) function that runs before or after a database event, like record creation or an API request.

“We added an onRecordAfterCreateRequest hook on the orders collection to send a confirmation email — no separate queue or serverless function needed.”

Extending with Go — since PocketBase is a Go framework as much as a product, teams can import it as a library and add fully custom routes and logic.

“For the payment webhook, we’re not using a hook — we extended PocketBase as a Go library and registered a custom route directly.”

Admin dashboard — the built-in web UI for managing collections, records, and settings, included in the same binary as the API.

“Non-technical teammates manage the faqs collection directly through the admin dashboard — no separate CMS integration needed for that content.”

---

Common Mistakes

• Calling PocketBase “just SQLite” — SQLite is the storage layer, but the realtime API, auth rules, and hooks are what make it a backend-as-a-service, not just a database file.
• Writing auth logic entirely on the frontend and skipping API rules — the rules are the actual enforcement layer; frontend checks are just UX.
• Assuming “single binary” means “not production-ready” — it describes the deployment model, not the feature set or scalability ceiling.

Practice Exercise

1. Explain, in two sentences, the difference between a collection rule and a hook to someone new to PocketBase.
2. Write a short PR description for adding an onRecordAfterCreateRequest hook that sends a welcome email on signup.
3. Draft a message to a teammate explaining why an auth rule, not a frontend check, should gate access to private records.

Related Resources

• English for Supabase Developers
• Go (Golang) Vocabulary
• Database Vocabulary

Navigating Nuance: Professional Communication for Developers

The core vocabulary of PocketBase – collections, realtime subscriptions, authentication, hooks – is critical, but mastering how you communicate about it in a professional setting elevates your development game immensely. For non-native English speakers, this often means more than just knowing the definitions; it’s about understanding subtle phrasing and how native developers typically express themselves when discussing technical challenges or proposing solutions. One common pitfall is over-literal translation. What sounds perfectly logical in your first language might feel clunky or even confusing to a team accustomed to specific, established English usage within software development.

Consider a code review comment: “The field username needs validation against the regex.” While technically correct, it’s a bit dry and lacks context. A native speaker would likely say something like, “Could we add some validation to ensure the username conforms to our expected format? It’s important for security reasons.” This phrasing immediately conveys why the change is needed – security – making the reviewer more receptive. Similarly, in Slack discussions regarding a new feature, simply stating “I’ve added a hook” isn’t enough. A better approach would be: “I’ve implemented a hook to handle [specific event], which will trigger [desired action]. This should improve [performance/user experience] as we’ve identified in the initial design.” The addition of specific details and their impact demonstrates a deeper understanding and proactively addresses potential concerns.

Another frequent scenario involves writing Pull Request (PR) descriptions. Instead of “Fixed bug,” a more effective description would be: “Resolved an issue where users were intermittently experiencing errors during [specific operation]. This was caused by [brief explanation] and the fix implements [solution briefly explained]. Added tests to ensure this issue doesn’t reappear.” The detail here isn’t just about fixing a bug; it’s about clearly documenting the problem, its root cause, and the implemented solution – crucial information for future developers maintaining the codebase. Focus on clarity, conciseness, and always explaining the “why” behind your changes.

Finally, paying attention to established terminology within Go development is key. Using phrases like “upstream” or “downstream” when discussing dependencies helps avoid ambiguity and demonstrates familiarity with standard software engineering practices.

Here’s an example of a pocketbase CLI command to illustrate a common data manipulation task:

pocketbase db hook create user_email_validation --script "func ValidateEmail(email string) bool { ... }"

This simple command, when discussed within a team, might be described as “We’re leveraging the db hook functionality to add email validation logic – this ensures data integrity and prevents invalid entries from being added to our user collection.” The key is connecting the technical action (the CLI command) with its purpose.