Collections

Collections provide structured data storage on the platform. They follow a familiar relational model — bases act as databases, collections act as tables, fields define columns, and records store rows.

Collections are used to store application data: customer records, product catalogs, configuration entries, analytics data, and anything else your application needs to persist.

Data hierarchy

Base (database)
└── Collection (table)
    ├── Fields[]            → column definitions
    │   ├── kind            → text, number, date, select, link, ...
    │   ├── validation      → rules and constraints
    │   └── options[]       → for select/choice fields
    ├── Views[]             → saved query configurations
    └── Records[]           → data rows

Bases

A base is a logical container for related collections — similar to a database schema. Each base maps to an isolated data store.

Bases can be linked to a blueprint via a blueprintId. When an app is installed, the platform can provision the base and its collections in the installing organization's scope.

Collections

A collection is a structured table within a base. It defines:

• A set of fields (columns) with types and validation
• Views — saved filter, sort, and field visibility configurations
• Records — the actual data rows

Fields

Fields define the schema of a collection. Each field has a kind (type) and optional configuration.

Records

Records are individual data entries (rows) in a collection. Each record contains values for the fields defined in the collection schema.

Views

Views are saved configurations that control how records are displayed — which fields are visible, how records are filtered, and in what order they appear.

Build-time vs. runtime

Collection schemas (field definitions, types, validation rules) are defined in the blueprint at build time. They describe the structure of the data.

Collection records (actual data) are created at runtime, per organization. Each organization that installs the app gets its own isolated set of records.

This means:

• The blueprint author defines a "Contacts" collection with fields for name, email, and phone
• Organization A installs the app and creates 500 contact records
• Organization B installs the same app and creates 200 different contact records
• Both use the same schema but have completely separate data

In this section

• Fields and Types — the available field types and validation options
• Records — creating, reading, updating, and querying records
• Views — saving and applying query configurations