How do I reuse SQL values across staging and production without rewriting the query?

In Staging the same statement wants a small LIMIT, a test id, a fake email, or a tighter filter. In Production those values are different.

Without a place to keep them, the number is pasted into every statement. When the tab moves from Staging to Production, you edit it by hand. A native SQL bind ($1, ?) fills a parameter for that run. It does not keep a value per environment, and it does not follow the tab.

Kerry Studio handles this with variables in SQL: a name bound to a value, a literal, a $faker. generator, or a SQL fragment. The value lives in the Variables panel. At run time, Kerry swaps the token and sends the database the SQL already resolved. The statement in the editor stays the same.

This is not a native engine bind. It is substitution in the client. The database receives SQL with the value already in place.

How to create the variable

You need an open workspace and a SQL tab.

From the editor

1. Write :variable in the query, for example :order_cap.
2. Press space.
3. Click the + next to the name.
4. The Variables panel opens on that row. Enter the value and the type, if it is not text.

From the panel

1. Open the Variables panel: the icon in the right sidebar, or the palette (⌘K / CtrlK) → Open Variables Panel.
2. Click New Variable.
3. Enter the identifier without the :.
4. Choose type, scope (Local or Global), and the environment whose value you are editing (Default or a project environment).
5. Fill in the value. In the editor, use :variable.

Local applies in one workspace. Global applies in all of them.

One value per environment

There are two ways to write the variable.

:variable, for example :order_cap, uses the value for the environment the tab is on. If that environment is empty in the panel, the Default value is used.

:variable:environment, for example :order_cap:production, uses that environment’s value even if the tab is on another one. The : sits only between the name and the environment.

In Postgres, two colons in a row are a cast: :order_cap::text means “the order_cap variable, converted to text”. That does not pick an environment. For Production, use :order_cap:production.

In the panel, one row is one name. The environment selector does not create another variable. It only switches which value of that row you are editing.

If order_cap is 50 in Staging and 500 in Production:

SELECT id, total
FROM orders
WHERE total >= :order_cap
ORDER BY total DESC;

If you change the value in the panel, the query stays the same. If the tab moves from Staging to Production and the SQL uses :order_cap without a locked environment, the database receives 500 instead of 50.

Text, number, or a SQL fragment

The SQL type stores a WHERE, a JOIN, or an expression and drops it into the statement without quotes. If several queries share the same active-row filter:

:active_filter (SQL) = status = 'active'

SELECT *
FROM orders
WHERE :active_filter;

Generate test data with $faker.

$faker. in the variable’s value generates a new value on every run. A test email, for example:

:test_email (Text) = $faker.internet.email

INSERT INTO customers (email)
VALUES (:test_email);

$faker. also works directly in SQL ($faker.person.fullName). On a variable, the same generator is reusable. Comments and strings in the SQL are not treated as variables.