Collections and data modeling
Choose a collection type and shape a maintainable PocketBase data model.
Choose a collection type according to how data is written, queried, and secured. Then keep each collection focused on one kind of application entity so that fields, relations, indexes, and API rules remain understandable as the application grows.
The collection model
A collection represents application data and is backed by a generated SQLite table. A record is one item in that collection. PocketBase supports three collection types:
| Type | Use it for | Write behavior |
|---|---|---|
| Base | Application data such as posts, products, or projects | Records can be created, read, updated, and deleted according to API rules. |
| View | Aggregations or custom read models from a SQL SELECT statement | Read-only; it has no create, update, or delete operations and does not emit realtime events. |
| Auth | Users, members, staff, or other independently authenticated populations | Base-collection behavior plus authentication fields and a Manage rule. |
Use a Base collection when the application owns the records. Use a View collection when the result is derived from other data and should not be edited directly. Use an Auth collection when a distinct user population needs its own login and record-management endpoints; you can have multiple Auth collections, such as members and staff.
Design fields around the record
Start with the fields required to describe one record. PocketBase fields are non-nullable by default and use a type-specific zero value when a value is missing; for example, text uses "" and number uses 0. JSON is the exception and can contain null. Add a relation when the value is another record rather than copying that record's mutable data into text fields.
An Auth collection includes the system fields email, emailVisibility, verified, password, and tokenKey. You cannot rename or delete them, but you can configure options such as whether email is required. Add application fields such as a role or display name alongside these system fields.
Choose a relationship strategy
For ownership, add a relation from the owned collection to the Auth collection. A posts.author relation, for example, lets a rule compare the author to @request.auth.id. For groups, a select field can represent a small, stable set of roles. Use a relation when membership is a record relationship or needs its own lifecycle.
Indexes support lookup and uniqueness decisions, but they do not replace API rules. Treat schema design and access design as related decisions: every field that can be filtered or compared by a rule should have a clear meaning and safe visibility.
Apply the model
Create the collection in the Dashboard or through the supported Web APIs and migrations. Define the fields first, add relations and indexes, then configure the collection's API rules. For a View collection, validate the SQL result shape before building client code against its field names.
Next, review the complete field, relation, index, and validation reference, then secure each operation with API rules and filters.