Giving a collection a schema
From your project's Data tab, a collection can be given a schema, its expected fields, each with a type and whether it's required. Once set, every insert, update, or upsert into that collection is checked against it first and rejected with a clear error if something's missing or the wrong type. A collection with no schema keeps accepting any shape, exactly as before, a schema is opt-in, not a migration you're forced into.
A schema field can also be marked unique (a write is rejected if another row already holds that value) or typed as a reference to another collection (a write is rejected unless the row it points at actually exists).
The records browser
The Data tab is a full editor for a collection's rows: page through them, filter by text, add or edit a row inline, delete one, and export the whole collection as CSV or import rows from a pasted CSV.
Per-key row ownership
A Database Query block can be set to per key ownership instead of the default shared mode: each row it inserts is stamped with the calling API key, and reads/updates/deletes only ever reach rows that same key created. A ready-made way to build a multi-tenant API without writing your own ownership checks into every block.
Background jobs
The Enqueue block hands off work to run later instead of during the current request: it records a target endpoint and a payload, then returns immediately. A scheduled job drains the queue in the background, retrying a failed job automatically before giving up. Use this for anything that could take longer than a single request should, sending a batch of emails, calling a slow partner API once per item in a list.
Tip: A schema doesn't just protect your data, it also makes your endpoint's generated OpenAPI documentation more precise, since a required or typed field shows up there automatically.