Guide
A shared SQL query library helps teams save, organize, run, and schedule trusted operational SQL instead of losing it in Slack and local files.
Every technical team has useful SQL scattered across laptops, Slack threads, admin tools, and old incident notes. Some queries answer customer questions. Some help support understand a broken workflow. Some become weekly operations checks. Most of them live in places where the next person cannot reliably find them.
A shared SQL query library gives that operational knowledge a home. The team saves trusted SQL once, adds a name and description, defines variables for the values that change, and runs it through the private database agent when needed.
Taavik gives teams a shared SQL query library, a path to schedule a saved query, and context from database documentation so the query is not separated from the schema it depends on.
Operational SQL is usually created under pressure. A support case is urgent. A finance check needs an answer before the meeting. An incident needs a quick view of affected rows. Someone writes a query, gets the answer, and moves on.
The query may be useful again, but it is rarely stored in the right place. It ends up in:
final_query.sql.This creates repeated work. The next person starts from scratch or asks the same teammate again. The SQL became knowledge, but the team did not capture it.
Not every query should be shared. Some queries are experiments. Some are one-off debugging notes. A useful query library needs both personal scope and company scope.
Personal scope is where a user can draft, test, and keep private working queries. Company scope is where the team stores trusted operational SQL. The difference should be visible because shared queries become part of the team's operating surface.
When a query moves into company scope, it should have a clear name, a short description, and variables for values that should not be edited directly in SQL text.
The best shared queries are reusable. Reuse usually depends on variables.
Common variables include:
Variables keep the query stable while letting the user change inputs. Defaults make the common case fast. Overrides make the query useful for a specific run.
This is safer than asking each user to edit raw SQL every time they need a different customer or date range.
For private databases, the query library should not require direct cloud database access. Taavik runs saved queries through the on-premise agent.
The cloud workspace stores the query definition, variables, folder, version history, and audit metadata. The agent runs the query from inside the network where the database is reachable.
Use a read-only database role. DML and DDL are rejected before dispatch, and the agent enforces statement timeouts. That keeps the library focused on read-oriented operational workflows.
The natural next step after saving a trusted query is scheduling it.
A support query may become a daily check. A finance query may become a Monday morning export. A data quality query may become a weekly Slack delivery. The important point is that the schedule should start from the same saved query the team already trusts.
That avoids the old pattern where the manual SQL and the scheduled SQL drift apart.
Start with queries the team already reruns:
Do not try to migrate every old SQL file on day one. Pick the queries that people ask for every week.
A shared query without a description is still better than a lost query, but it is not enough.
The description should explain when to use the query, what the result means, and any caution the runner should know. This is not documentation for the whole database. It is context for a specific operational action.
Good descriptions are short. They explain intent, not every line of SQL.
Once a query is shared, the team needs visibility into execution. Who ran it, when, against which connection, with which variables, and what happened?
Run history answers those questions. It helps with support, post-incident review, compliance review, and team learning.
A shared SQL query library is not only storage. It is a controlled workflow for operational SQL.
Save the SQL your team already trusts.