Data model

Field types

Field types drive API validation, physical constraints, defaults and dashboard editing.

Type	JSON input	Good fit
`text`	String	Names, titles and descriptions
`number`	Number	Scores, quantities and prices
`boolean`	Boolean	Binary states
`datetime`	UTC timestamp string	Deadlines and event times
`json`	Any structured JSON	Variable metadata
`select`	Declared string choice	Controlled workflow states
`relation`	Record ID string	References to records
`email`	Email string	Contact addresses
`url`	URL string	External links

Example values

{
  "title":"Investigate delivery retry",
  "priority":3,
  "resolved":false,
  "due_at":"2026-09-01T09:00:00Z",
  "status":"open",
  "owner_id":"rec_user_123",
  "metadata":{"source":"support"}
}

Common flags

required becomes a non-null constraint, unique becomes a uniqueness constraint, and defaults are validated against the field type before schema commit. Unknown fields and wrong JSON types produce indexed validation errors before SQLite is asked to write.

Relations

Relation values are validated record ID strings and can participate in rules. Target-collection and delete/update policy metadata are still required before Trestle can generate physical foreign-key constraints for relation fields.

Provider storage

Field types are a logical contract. SQLite stores them as STRICT text/real/integer with typed checks; the PostgreSQL provider uses native TEXT, DOUBLE PRECISION and BOOLEAN columns. Application validation and error envelopes are identical; only the physical mapping differs. See Physical schema.