Introduction - Collections - Docs

Overview

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

Single entry of a collection is called record (a single row in the SQL table).

You can manage your collections from the Dashboard, with the Web APIs using the client-side SDKs (superusers only) or programmatically via the Go/JavaScript migrations.

Similarly, you can manage your records from the Dashboard, with the Web APIs using the client-side SDKs or programmatically via the Go/JavaScript Record operations.

Here is what a collection edit panel looks like in the Dashboard:

Currently there are 3 collection types: Base, View and Auth.

Base collection

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

View collection is a read-only collection type where the data is populated from a plain SQL SELECT statement, allowing users to perform aggregations or any other custom queries in general.
For example, the following query will create a read-only collection with 3 posts fields - id, name and totalComments:

SELECT
    posts.id,
    posts.name,
    count(comments.id) as totalComments
FROM posts
LEFT JOIN comments on comments.postId = posts.id
GROUP BY posts.id 

View collections don't receive realtime events because they don't have create/update/delete operations.

Auth collection

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

Each Auth collection has the following special system fields: email, emailVisibility, verified, password and tokenKey.
They cannot be renamed or delated but can be configured using their specific field options. For example you can make the user email required or optional.

You can have as many Auth collections as you want (users, managers, staffs, members, clients, etc.) each with their own set of fields, separate login and records managing endpoints.

You can build 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: "employee" and "staff". And then in some of your other collections you could define the following rule to allow only "staff":
@request.auth.role = "staff"
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, including back-relations, are also supported, for example: 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 (e.g. 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 = "staff" || author = @request.auth.id)

Fields

All collection fields (with exception of the JSONField) are non-nullable and uses a zero-default for their respective type as fallback value when missing (empty string for text, 0 for number, etc.).

All field specific modifiers are supported both in the Web APIs and via the record Get/Set methods.