PRACTICAL FIELD GUIDE
JSON column or related table for nested data?
A JSON field is useful for flexible payloads, while related tables make frequently queried relationships more explicit. Choose based on the operations the generated API must support.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- List which nested values need filtering, sorting, uniqueness or independent access control.
- Model frequently operated-on entities as supported tables and relationships.
- Use JSON for genuinely flexible data and validate its shape in the application.
What this looks like
ILLUSTRATIVE EXAMPLE
A settings object is read as a whole, but order items need individual quantities and references. They need not use the same storage pattern.
A boundary to keep clear
Do not assume the generated REST API exposes arbitrary JSON-path querying just because SQLite can store JSON text.
MCPBackend context
MCPBackend stores each project's data in SQLite and exposes supported tables through generated REST endpoints. Use the schema tools and dashboard for supported changes. The design examples here are patterns to adapt, not claims that the API exposes every SQLite feature or arbitrary SQL.
Take the next step
Inspect the current project contract, try the change with disposable data, and verify the result through the same credentials your app will use. Record the expected response and one denied-access case before release.
Sources and further reading
These references explain the underlying protocols and design principles. For supported MCPBackend operations and exact request shapes, inspect your project’s generated API contract.