Full-Text Search
Tables declare what is searchable. Two field-level properties control how a field participates in search: indexed makes it queryable, and fullTextSearch (on rich-text) enables FTS indexing for formatted content. Components then pick the engine that consumes these — see search-overview.
Field properties
| Property | Applies to | Description |
|---|---|---|
indexed |
All field types | Boolean. Creates a database index on the field. Required for fts, trigram, and hybrid engines. |
fullTextSearch |
rich-text |
Boolean. Enables full-text-search indexing for the field's formatted content. |
These extend the base field properties shared by every field type.
Declaring searchable fields
Mark every field you want the fts, trigram, or hybrid engines to reach with indexed: true. A rich-text field additionally needs fullTextSearch: true, because its stored value is HTML markup rather than plain text.
tables:
- name: articles
fields:
- { id: 1, name: title, type: single-line-text, indexed: true }
- { id: 2, name: summary, type: long-text, indexed: true }
- { id: 3, name: tags, type: single-line-text, indexed: true }
- { id: 4, name: body, type: rich-text, indexed: true, fullTextSearch: true }Every indexed field contributes equally to the relevance score. There is no per-field weighting: a match in title and a match in body count the same. Rank by recency or another sort key when you need one field to dominate.
fullTextSearch on rich text
The rich-text field stores formatted HTML. Setting fullTextSearch: true enables full-text-search indexing of its text content so the field can participate in fts/hybrid queries alongside plain-text fields.
- id: 5
name: article_content
type: rich-text
required: true
maxLength: 10000
fullTextSearch: true
toolbar: [bold, italic, link, heading, list]Plain long-text and single-line-text fields do not need fullTextSearch — set indexed: true and they are FTS-ready. The fullTextSearch flag exists specifically for rich-text because its stored value is HTML markup rather than plain text. See text-fields for the full rich-text property set.
PostgreSQL vs SQLite
| Aspect | PostgreSQL | SQLite |
|---|---|---|
| FTS engine | Native tsvector/tsquery relevance ranking. |
Simpler matching; ranking is reduced. |
| Fuzzy matching | pg_trgm extension (trigram, typo-tolerant). |
Not available — trigram engine targets Postgres. |
| Recommendation | Use for index-backed fts/trigram/hybrid search. |
Zero-config default; design ranked search on Postgres. |
SQLite is Sovrium's zero-config default database. For production search that depends on ranked relevance or fuzzy matching (trigram/hybrid), run against PostgreSQL where tsvector and pg_trgm are available.
Trigram fuzzy matching
The pg_trgm extension breaks text into three-character sequences (trigrams) and matches on overlap, tolerating typos and partial words. This powers the trigram and hybrid engines. A field used for fuzzy search should be indexed: true so PostgreSQL can build a trigram (GIN/GiST) index.
tables:
- name: products
fields:
- { id: 1, name: name, type: single-line-text, indexed: true }# Component side — fuzzy matching on the indexed field
- type: data-table
dataSource:
table: products
mode: search
searchFields: [name]
searchEngine: trigramA query of prodct still matches product; lapto matches laptop. Pair trigram with FTS using searchEngine: 'hybrid' to keep relevance ranking for exact terms while retaining typo tolerance for the rest.
Related
- Search Overview — the four search engines and the
searchdata-source mode. - Search Components —
searchInput,list,pageSearch, and toolbar search. - Text Fields —
rich-text,long-text, and thefullTextSearchflag. - Tables Overview —
indexedand other base field properties.
Last updated August 11, 2026
This documentation was written with AI, so errors or outdated content are possible. Sovrium is in beta. Contributions and corrections are welcome.