Creating Custom SQL Queries

Use custom SQL when the query builder stops expressing the real query clearly

Custom SQL is useful when the visual query builder is no longer the clearest way to express what the database needs to do. The goal is not to abandon Wappler’s data tooling. The goal is to keep complex query intent readable while still returning structured output to the rest of your app.

Expressive queries

Write the join, filter, grouping, or database-specific syntax you actually need.

Predictable contract

Return named fields your page or action can consume confidently.

Parameter safety

Keep input values parameterized instead of concatenated.

Reach for custom SQL when the query itself is clearer in SQL than in the builder.

Keep the output shape explicit so the rest of the app stays understandable.

Treat parameters as data, not string fragments you splice into the query.

A practical pattern is start from the result shape, then write the smallest query that produces it

The safest way to begin is to define what rows and columns the page or workflow actually needs, then write the query around that requirement. This keeps the SQL focused, makes output naming deliberate, and reduces the temptation to return a giant dataset the UI does not need.

Define the result contract first: which records and which fields matter.

Parameterize filters such as id, search, or date boundaries instead of building strings.

Test the output as JSON so the page or downstream step sees a stable response shape.

Next steps

Use the related tours below when you want more context about how custom SQL fits into the larger Wappler data workflow.