Custom Fields vs. a Database: When Flat JSON Is Actually Enough

"You need a database for structured data" is one of those assumptions that goes mostly unquestioned — until you look at what most sites actually store. A price. A duration. A checkbox. A dropdown with five options. None of that needs a relational schema, foreign keys, or a query language. It needs a place to put a value and a way to read it back.

That's what Custom Fields in Synaptik CMS are built for.

How the schema works

Custom Fields are defined once, per content type, in Settings → Custom Fields. Each field has a label, a machine key, a type (short text, long text, number, URL, checkbox, or dropdown), and an optional required flag. That schema lives in settings.json — a single, human-readable block:

"custom_fields_schema": {
  "article": [
    { "key": "duration", "label": "Duration", "type": "text", "required": false },
    { "key": "price",    "label": "Price",    "type": "number", "required": true }
  ]
}

Once a field exists in the schema, a Custom Fields tab appears in the editor for that content type, and values get saved directly inside the item's own JSON file:

{
  "title": "My article",
  "custom_fields": { "duration": "45 min", "price": "80" }
}

What you'd actually lose without a database

The honest answer: querying across items by a custom field value is not free. render_item_custom_fields() and get_custom_field() both operate on a single loaded item — filtering or sorting a whole content type by a custom field requires loading every item file, which the core makes possible via sl_load_all_items(), but that's explicitly documented as the expensive path.

For most real use cases — a price shown on a project page, a duration badge on an article, a URL field rendered as a link — that trade-off doesn't matter. You're reading one field, on one page, for one item. That's the majority of what custom fields get used for in practice, and it's exactly the case flat JSON handles without any overhead.

Where the line actually is

If you need to filter a catalog of 500 items by a numeric range, or run anything resembling a real query, a database will do it faster and with far less code. But that's a different product problem than "I want to show a price on my article template" — and conflating the two is how simple sites end up carrying database weight they never needed.

Custom Fields in Synaptik CMS are deliberately scoped to the case that covers most sites: structured, per-item data, read where it's needed, with zero extra moving parts to install, configure, or keep patched.