Safety-first Slack → SQL, with confirm-before-run.

Demo video

Paste your Cloudflare Stream (or YouTube/Loom) embed below.

Become a design partner

If you’re willing to share real questions and workflows, we’d love your input. In return, you’ll get early access and a real chance to influence how the product works from the start (UX, guardrails, and the questions it supports). Send 2–3 recurring questions and a bit of context. We’ll reply with (1) whether it’s a fit, (2) a suggested first workflow, and (3) a realistic timeline. A safe sandbox setup is optional later — we won’t ask for database access up front.

What this is / what it isn’t

Clear expectations on safety, scope, and early beta limitations. Last updated: 2026-01-15

What this is

• A Slack-native assistant for asking questions in natural language and getting answers from your team’s database.
• A confirm-before-run SQL workflow: the bot proposes SQL, you review it, then explicitly approve execution.
• A safety-first query runner:
  • read-only execution (intended to be used with a read-only DB role)
  • SELECT / WITH … SELECT only
  • single statement only
  • enforced row limits and short statement timeouts
  • basic “risk” messaging (e.g., encourages narrower windows / previews)
• A human-in-the-loop tool: you stay in control of what executes.
• A Postgres-first prototype today, designed to evolve toward adapters for other databases.

What this is not

• Not “an AI that can do anything in your company.” It’s focused on answering data questions via SQL.
• Not an auto-executing agent. It does not run queries without an explicit confirmation step.
• Not a write tool: no INSERT, UPDATE, DELETE, schema changes, or admin actions.
• Not a replacement for your governance program, BI layer, or data team.
• Not guaranteed to be correct: results can be wrong if the question is ambiguous, the schema is misunderstood, or the data is incomplete.
• Not production-ready for every environment yet (early beta constraints apply).

Safety and trust model (plain English)

• You see the SQL before it runs.
• Queries are constrained (read-only, row limits, timeouts).
• If in doubt, do not run: if something looks unsafe or unclear, it blocks or asks for refinement.
• You can see what ran: the Slack message shows the SQL and results; durable audit logs (what ran, when, and by whom) come later.

What you should expect in early beta

• Limited coverage: the bot may only handle a subset of question types well.
• Occasional “I don’t know” / “please refine” moments.
• Performance constraints: large datasets may require narrower filters or previews.
• UI is intentionally conservative: more confirmations than you might want at first.

What you need to provide (for a real sandbox)

• A Postgres connection string to a sandbox/staging database (or read replica).
• A read-only DB user (recommended) with access limited to approved schemas/tables.
• Basic context:
  • what tables represent (short descriptions)
  • which timestamp column(s) define “recent”
  • any do-not-touch tables/columns

How to use it effectively

• Ask questions with a clear scope (e.g. “last 7 days”, “this week”, “by customer”, “P1 only”, “queue = X”).
• Prefer starting with a preview or narrower window if the query might be large.
• Treat results as a starting point and validate against known dashboards/reports.

Support and feedback (what helps most)

• Your top 5 recurring questions (copy/paste is fine).
• A sample schema screenshot or table list.
• One example of a “correct” query/result you already trust.

Roadmap hints (near-term)

• Generic safety-first UX improvements (preview runs, explain/cost checks).
• Per-customer allowlists, masking rules, and stronger audit logging.
• Better NL→SQL coverage with guardrails.