For CS, SRE, and engineering

Approve the query before it runs

Admin creates users, sets permissions, and picks default approvers per database. You write the query, attach a Jira ticket, add a rollback and a reason. Approvers get Slack and email. Nothing runs without their message and their yes — now or on a schedule.

Approval
Slack and email
AI suggestions
Jira comments
Query templates
Audit trail
Learn More

What you get on every request

Users and permissions from admin. A query, a ticket, a rollback, and a reason from the requester. A human yes with a message. Then Slack, email, history, and Jira if you turn it on.

THE WORKFLOW

How Query Setu Works

Write the request. Send it. Approvers get Slack and email. They approve or reject with a message. Then you run it, or schedule it. History stays on the request.

Step 1 of 6

BEFORE & AFTER

The old way vs. Query Setu

Same moment. One side is a Slack DM and a shared password. The other is a request with an approver, a rollback, a schedule, and a history you can open.

The old way

How production queries happen today

With Query Setu

The same work, with a yes and a trail

Where CS and SRE stop rewriting the same query

Grant a permission. Create a customer account. Run a write. Clone last time. The values change. The path does not.

YOUR STACK

Works with your tech stack

SQL databases, PostgreSQL, MongoDB, and Redis. Production or not. Slack and email when a request is sent. Jira comments if an admin turns them on.

Supported Databases

The same request path on SQL databases, PostgreSQL, MongoDB, and Redis.

SQL databases
PostgreSQL
MongoDB
Redis

Integrations

Slack and email when a request is sent. Jira comments on that ticket if an admin has configured them.

Slack
Email
Jira comments
SECURITY

Guardrails you can use. Not a compliance badge.

Query Setu is a new product. We are not SOC 2, HIPAA, or GDPR certified, and we will not put those logos here. What we can stand behind is a human yes with a message before a query runs, history on the request, and Jira comments if an admin turns them on.

What we do today

  • A person approves or rejects with a message. Without that, the query does not run.
  • Slack and email go out when the request is sent.
  • If AI has a suggestion, it is attached to the request. It does not approve or run anything.
  • The request holds the history: who asked, the rollback, the approver’s message, and what ran.
  • If an admin configures Jira, those same updates post as comments on the ticket.
  • Admin creates users, sets permissions, customizes dashboards, and defines default approvers per database.
  • The platform connects after a yes. Nobody pastes a production login into Slack.

What we are not claiming

  • SOC 2, HIPAA, GDPR, or any other formal certification. We do not have them.
  • A replacement for your security or compliance program. We are a request path, not a GRC suite.
  • Published details on encryption, SSO, or data residency. We have not shipped those docs yet.
  • That accidents become impossible. A second pair of eyes is not a guarantee.
  • That AI is a control. A human still decides. There is no bypass that skips approval.

Approval before writes

A query does not run until a person reads it and says yes.

Audit trail

Who asked, what AI said, who approved, what ran. Searchable when you need the log.

Jira stays the ticket

Open or attach a ticket. Each status posts as a comment where the team already works.

Roles, not a shared login

Request, approve, or read-only. A requester does not get an implicit yes.

If you need a certified vendor for regulated data today, we are not that vendor yet. If you need fewer shared passwords and a record of who approved what — including the Jira thread — that is the product.

FREQUENTLY ASKED QUESTIONS

How requests, approvals, and Jira work

Users, default approvers, Slack and email, templates, cloning, post-actions, and the request history.

Query Setu is the approval path for database work. An admin creates users, sets permissions, and customizes dashboards. A requester writes the query, attaches a Jira ticket, names the approver, adds a rollback, and explains why. AI can leave a suggestion on the request. Approvers get Slack and email. Nothing runs until they approve or reject with a message. Then you run it now or schedule it. The request keeps a full history. Jira can get the same updates as comments if an admin turns that on.

An admin. They create users, assign permissions, and customize dashboards. They also set default approvers per database, optional Jira comments, and optional default post-actions on a database or table so requesters do not have to configure those every time.

The query, a Jira ticket, the approver (or the database default), a rollback query, and a short message that says what this is and why it needs to run. Then they send it.

Admin defines default approvers for each database in customization. The requester can still name an approver on the request. If they do not, the database default is used.

No. An approver must approve or reject with a message. Without that approval, the query does not run.

When a request is sent, people get a Slack notification and an email (Gmail or whatever inbox they use). The request already includes the query, the reason, the rollback, the Jira ticket, and any AI suggestion.

If AI has a suggestion, it is attached to the request so the approver can see it. AI does not approve the query and does not run it. A person still decides.

Yes. After approval, run it immediately or pick a time. The same request, the same rollback, the same audit history.

Work that runs after the query succeeds. A requester can define post-actions on that run. An admin can also set default post-actions on a database or table in customization, so the team does not set them up every time.

Yes, if an admin configures it. The request can carry a Jira ticket, and Query Setu posts the request history as comments: submitted, approved or rejected, scheduled, ran, and post-actions. If Jira is not configured, the request history still lives in Query Setu.

The history on the request: who wrote it, the query, the reason, the rollback, any AI suggestion, who was asked, the approver’s message, the decision, when it ran or was scheduled, post-actions, and Jira comments if those are on. You open the request. You do not reconstruct it from Slack.

Saved queries for work CS and SRE repeat — grant a permission, create a customer account, and similar jobs. The statement stays the same. The values change, and Query Setu takes those values. Then the usual path: approver, Slack and email, optional AI suggestion, run or schedule, audit history.

Yes. Clone an earlier request when the work is the same and only the values or the ticket changed. You still need a fresh approval before it runs.

SQL databases, PostgreSQL, MongoDB, and Redis. Same request path on each connection.

No. Query Setu is a new product and does not hold SOC 2, HIPAA, GDPR, or any other certification. Those are later goals, not a current claim.

Yes. We are planning more, and we will add them when they are real. This page only describes what the product is built to do now: requests, approval, Slack and email, Jira comments, templates, cloning, post-actions, and audit history.

READY WHEN YOU ARE

Stop pasting queries
into Slack

Put the query on a request. Get a yes with a message. Keep the history — and the Jira comments, if you want them.

Email us