Overview

    Collections represents your application data.
    Under the hood they are plain SQLite table that are generated automatically with the collection name and fields (aka. columns).

    Single entry of a collection is called record - aka. a single row in the SQL table.

    PocketBase comes with all sort of fields that you could use:

    Field Supported value
    text "", "example"
    number 0, -1, 1, 1.5
    bool false, true
    email "", "test@example.com"
    url "", "https://example.com"
    date "", "2022-01-01 00:00:00.000Z"
    select (single) "", "optionA"
    select (multiple) [], ["optionA", "optionB"]
    file (single) "", "example123_Ab24ZjL.png"
    file (multiple) [], ["example123_Ab24ZjL.png", "example456_Frq24ZjL.txt"]
    relation (single) "", "JJ2YRU30FBG8MqX"
    relation (multiple) [], ["JJ2YRU30FBG8MqX", "eP2jCr1h3NGtsbz"]
    json any json value

    You could create collections and records from the Admin UI or the Web 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 panel looks like:

    Collection panel screenshot

    Currently there are 2 collection types: Base and Auth.

    Base collection

    Base collection is the default collection type and it could be used to store any application data (eg. articles, products, posts, etc.).

    It comes with 3 default system fields that are always available and automatically populated: id, created, updated.
    Only the id can be explicitly set (15 characters string).

    Auth collection

    Auth collection has everything from the Base collection but with some additional special fields to help you manage your app users providing various authentication options.

    Each Auth collection comes with the following system fields: id, created, updated, username, email, emailVisibility, verified.

    You can have as many Auth collections as you want (eg. users, managers, staffs, members, clients, etc.) each with their own set of fields, separate login (email/username + password or OAuth2) and models managing endpoints.

    You can create all sort of different access controls:

    • Role (Group)
      For example, you could attach a "role" select field to your Auth collection with the following options: "regularUser" and "superUser". And then in some of your other collections you could define the following rule to allow only "superUsers":
      @request.auth.role = "superUser"
    • Relation (Ownership)
      Let's say that you have 2 collections - "posts" base collection and "users" auth collection. In your "posts" collection you can create "author" relation field pointing to the "users" collection. To allow access to only the "author" of the record(s), you could use a rule like: @request.auth.id != "" && author = @request.auth.id
      Nested relation fields look ups are also supported, eg: someRelField.anotherRelField.author = @request.auth.id
    • Managed
      In addition to the default "List", "View", "Create", "Update", "Delete" API rules, Auth collections have also a special "Manage" API rule that could be used to allow one user (it could be even from a different collection) to be able to fully manage the data of another user (eg. changing their email, password, etc.).
    • Mixed
      You can build a mixed approach based on your unique use-case. Multiple rules can be grouped with parenthesis () and combined with && (AND) and || (OR) operators:
      @request.auth.id != "" && (@request.auth.role = "superUser" || author = @request.auth.id)