First run and the mental model

August 11, 2026

The win for today: a PocketBase server running on your machine, a real collection with API rules, and a JSON response from its API in your terminal. Roughly twenty minutes.

Key idea —

PocketBase is a single Go binary wrapping an embedded SQLite database. Run it and you get an admin dashboard, a REST API, and authentication — before writing any code. Your new product's backend starts as configuration, and becomes Go code only where you need it to.

1. Run it (5 min)

Download the binary from the official docs (or brew install pocketbase), then:

./pocketbase serve

That's the whole deployment story locally: one process on 127.0.0.1:8090, storing everything — schema, data, uploaded files — in a pb_data/ directory it creates beside itself.

Open http://127.0.0.1:8090/_/ and create your first superuser when prompted (or run ./pocketbase superuser create you@example.com yourpassword).

2. Model something (7 min)

In the dashboard, create a collection called posts. A collection is a SQLite table with a typed schema — PocketBase's unit of data modelling (Collections docs).

Give it three fields: title (text, required), body (editor or text), and published (bool). Save, then add two or three records by hand in the UI.

3. Hit the API (5 min)

Every collection automatically gets REST endpoints (Web APIs reference). Try:

curl http://127.0.0.1:8090/api/collections/posts/records

You'll get 403 or an empty result — and that's the most important lesson of the day. Access is governed by API rules on the collection, and new collections start locked to superusers.

Open the posts collection settings → API rules. Set the List and View rules to allow only published posts:

published = true

Re-run the curl. Your published records come back as JSON; unpublished ones don't exist as far as the public API is concerned.

Key idea —

Rules are filter expressions attached to collections — authorisation as data, not middleware. null (locked) means superusers only; an empty rule means anyone; an expression is evaluated per request against the record and @request.* context (API rules and filters). This one idea does the work that a stack of auth middleware does elsewhere.

Check yourself

Q1. What does a PocketBase collection correspond to under the hood?

Q2. Where does PocketBase's authorisation logic primarily live?

Q3. A collection's rule is null (locked). Who can access it via the API?

Primary source

Read the official Introduction and skim Collections — together about ten minutes, and the highest-trust material there is (it's the maintainer's own writing, kept current with the pre-1.0 releases).

Keep for reference

The compressed version of everything above lives in the mental-model cheat sheet — that's the one to come back to.

Lesson 2 will make rules real: an auth collection, users owning their own records, and the @request.auth context — the foundation the React Router frontend will authenticate against.