Building Vocab with PocketBase: More Time for the Learning Experience

Vocab started with a product problem: make English practice consistent enough to use every day. Building account management, a database administration screen, file handling, and basic data APIs from scratch would have taken time away from that problem. PocketBase gives the application a compact foundation, while the learning engine remains application code.

What PocketBase brings

PocketBase combines SQLite, authentication, a management dashboard, file handling, and data APIs. It can run as a standalone application or be extended with Go. For Vocab, I use the second approach: a Go application with PocketBase underneath, rather than a frontend that decides all of the learning rules.

This reduces the number of separate components I need to connect before a feature becomes usable. I can manage accounts and inspect records through the dashboard, define collections through versioned migrations, and spend more effort on practice behavior. It does not remove the need to design the data model or test the API.

The path from an answer to a saved result

The TypeScript/Vite interface requests a practice item from the Go API. When the learner answers, the backend checks the answer and updates the corresponding learning state. English-to-Turkish and Turkish-to-English histories are separate. Word, phrase, and sentence progress also remain separate, so a grammar exercise does not accidentally change a vocabulary score.

PocketBase supplies the persistence foundation; the custom Go routes implement the domain behavior. For example, choosing the next due item and deciding how an answer affects its next review are learning rules, not generic CRUD operations. Keeping them on the server makes the saved result authoritative when the learner moves to another device.

User data needs explicit boundaries

Vocab has multiple accounts, private images, and personal learning histories. Collection records are scoped to their owner. PocketBase's API rules control access to collection operations, but custom routes still need their own authorization checks. A dashboard permission is not proof that every custom endpoint has the same protection.

I would verify this with two test accounts: creating a record as one user must not let the other read or modify it simply by guessing its identifier. The same principle applies to private images, statistics, and AI-generated practice data. Superuser credentials belong to administration, not ordinary browser sessions.

AI is an optional service, not the database

The backend requests meaning suggestions, examples, and grammar assessment from Gemini, with a configured OpenRouter fallback. API keys stay on the server. Existing learning content and deterministic review logic can work without an AI key. Provider timeouts, invalid output, and quotas are separate concerns from whether a learning result was saved correctly.

Deployment stays small, operations remain real

Vocab is packaged with Docker and deployed through Dokploy. Its persistent PocketBase volume contains the database and uploads. Replacing the application image should not replace that data. A recovery plan needs a consistent backup and a tested restore, not only a copy of the Git repository.

The portfolio uses a separate PocketBase instance for project and blog content. Those records are independent of Vocab's users and progress. Sharing the same backend technology does not mean sharing a production database.

For this project, the benefit is fewer infrastructure pieces between an idea and a working feature. The trade-off is that migrations, access control, backups, and version upgrades still need attention. PocketBase remains under active development before 1.0; I would evaluate compatibility and operational requirements before choosing it for a critical system.

Sources

• PocketBase overview
• Extending PocketBase with Go
• API rules and filters

Published 20 October 2026; implementation and documentation checked on 29 October 2026.