Collections are where you application data live.
Internally Collections are plain SQL tables with some additional information for common data constraints and access rules.

When you create a Collection, a new table will be generated with the specified name and fields (aka. columns).
3 system fields are always created by default and cannot be changed manually - id, created, updated.

Single entry of a Collection is called Record - represents a single row in a SQL table.

You could create Collections and Records from the admin UI or the API.
Usually you'll create your Collections from the admin UI and manage your records with the API using the client-side SDKs.

Here is what the Collection form looks like:

Collection panel screenshot


Fields are the schema/structure of your Collection and its Records.

PocketBase comes with all sort of field types that you could use:
text, number, bool, email, url, single or multiple select, files upload, relations, etc.

API Rules

API Rules are your Collection access permissions and data filters.

Each collection has 5 rules, corresponding to the specific API action:

  • listRule
  • viewRule
  • createRule
  • updateRule
  • deleteRule

Each rule could be set to:

  • "locked" - aka. null, which means that the action could be performed only by an authorized admin (this is the default)
  • Empty string - anyone will be able to perform the action (admins, authorized users and guests)
  • Non-empty string - only those Record(s) and users (authorized or not) that satisfies the rule filter expression will be able to perform this action

Unlike Firebase, Pocketbase API Rules acts also as Records filter!
Or in other words, you could for example allow listing only the "active" Records of your collection, by using a simple filter expression such as: status = "active" (where "status" is a field defined in your Collection).

The API Rules are ignored when the action is performed by an authorized admin (admins can always access everything)!

Rules/Filters syntax

You could find information about the supported fields in your Collection API rules tab:

Collection API Rules filters screenshot

There is automplete to help you guide you while typing the rule filter expression, but in general, you have access to 3 groups of fields:

  • Your Collection schema fields - including all nested relations fields too, eg. somerelation.status != "pending"
  • @request.* filter fields - you could use them to access the current request data, such as query parameters, body/form data, authorized user state, etc.
  • @collection.* filter fields - you could use them to target other collections that are not directly related to the current one (aka. there is no relation field pointing to it) but both shares a common field value, like for example a category id field value: = categoryId && =

The syntax basically follows the format OPERAND OPERATOR OPERAND, where:

  • OPERAND - could be any of the above field literal, string (single or double quoted), number, null, true, false
  • OPERATOR - is one of:
    • = Equal
    • != NOT equal
    • > Greater than
    • >= Greater than or equal
    • < Less than or equal
    • <= Less than or equal
    • ~ Like/Contains (if not specified auto wraps the right string OPERAND in a "%" for wildcard match)
    • !~ NOT Like/Contains (if not specified auto wraps the right string OPERAND in a "%" for wildcard match)

To group and combine several expressions you could use brackets (...), && (AND) and || (OR) tokens.

  • Allow only registered users: != ""
  • Allow only registered users and return Records that are either "active" or "pending": != "" && (status = "active" || status = "pending")
  • Allow access by anyone and return only the Records where the title field value starts with "Lorem" (eg. "Lorem ipsum"):
    title ~ "Lorem%"