Guide
Use parameterized SQL queries for operational workflows, so teams can rerun trusted SQL with safe inputs and schedule recurring exports.
Operational SQL often changes only by customer, date, account, status, or environment. The structure of the query stays the same. The inputs change.
Parameterized SQL queries make that workflow repeatable. Instead of asking every user to edit the SQL text, the query exposes the values that are meant to change.
Taavik supports parameterized SQL queries, lets teams schedule parameterized SQL, and connects those schedules to scheduled SQL exports.
A value should become a variable when it changes between runs but the query logic stays the same.
Common operational variables include:
These values should be visible to the runner before execution. The person running the query should not have to search through SQL text to find what to change.
Defaults make parameterized queries faster to run. A data quality query may default to the last 24 hours. A finance query may default to the current month. A support query may have no default because the customer id must be explicit.
Overrides let each run provide the values needed for that case.
The goal is to keep the trusted SQL body stable while still making the query flexible enough for real operations work.
Date range and customer filters are the most common candidates.
Without variables, users edit the SQL by hand. That creates small risks:
With variables, the query tells the runner which values are expected. The SQL definition remains consistent.
Parameterized queries need audit. The team should know which values were used for each run.
Useful audit fields include:
This helps support, compliance, incident review, and routine operations. If someone asks what was checked for a customer, the run history should answer.
Some parameterized queries should run on a schedule.
For scheduled runs, the schedule stores its own variable defaults. A daily failed-payment export might set the date range to the previous day. A weekly data quality check might set a status filter and deliver the result to Slack.
The schedule should still point to the saved query. That keeps the query definition in one place while allowing scheduled runs to provide predictable inputs.
Parameterized SQL still runs against a real database, so the execution boundary matters.
Taavik runs queries through the on-premise agent. The workspace coordinates the saved query, variables, audit, and schedule. The agent connects from inside the private network.
Use a read-only database role. DML and DDL are rejected before dispatch. The agent enforces statement timeouts.
Start with queries the team already edits by hand:
If the SQL stays mostly the same and one value changes, it is a good candidate.
Add variables to the SQL your team reruns most.