Collections are how you model data. The platform ships with a large set of built-in types, and anything you define behaves identically to them.
Base and custom collections
Base collections are the built-in types — customers, products, orders, employees, events and so on. They are already modeled, indexed and exposed.
Custom collections are yours. Describe the fields, and the platform stores them, indexes them, gives them an editor and exposes them through the API.
A collection you create gets the same lifecycle, versioning, approval, permissions and API surface as a built-in type. There is no reduced tier.
Schemas describe data and its editor
A collection's schema does double duty: it validates the data and describes how each field should be presented. Set a field as a long text area, a code editor, a tree selector or a file picker, and the editor renders accordingly.
That is why a new collection has a working form the moment you define it — the presentation was part of the definition.
Fields can draw their options from another collection, so a select can be populated from your categories or your locations rather than a hard-coded list.
Sub-schemas
A sub-schema is a variant within a collection — different shapes of the same underlying type. Records carry which variant they are, and can be queried by it, so you can keep related-but-different things together without creating a separate collection for each.
Import and export
Data can be imported in bulk and exported as CSV or JSON. Exports stream and page internally, so exporting a whole collection is normal rather than something to avoid.
Bulk import can bypass the usual per-record processing, which includes search indexing. After a large import, re-index the collection or the records will not appear in search results.
Fixing a collection
If a collection and its schema fall out of step — a missing index, a collection that was never created — it can be reconciled rather than rebuilt.