Database analytics, in plain language
Most teams do not have an analytics problem. They have a queue. The numbers exist, the database has them, and getting at them means asking the one person who can write the query. ByeSQL removes that step: you ask in plain language, and the answer comes back as a number, a chart or a dashboard.
What self-service analytics usually means
And why most teams never get there.
- Someone needs a number
- They file a request or ask in Slack
- It waits behind the roadmap
- An analyst writes the query
- The answer arrives, raising two more questions
- Back to step two
- Someone needs a number
- They ask for it in plain language
- They refine it with a follow-up
- They pin it so nobody has to ask again
The questions that follow an answer are the point. Each one is a follow-up prompt, not a new ticket.
No warehouse, no ETL, no semantic layer
The conventional analytics stack exists to serve a scale most teams do not have yet. ByeSQL skips it and reads the database you already run.
Nothing to pipe
No extract to schedule and no second copy of the data drifting out of date. A refresh re-runs the query against the live database.
Nothing to model
No metrics layer to define before the first answer. Your schema (tables, views, keys and relationships) is the model.
Nothing to maintain
Nobody owns a definitions file that silently goes stale. When your schema changes, refresh the connection.
The questions teams actually ask
Real prompts, not a feature list.
When you should use something else
ByeSQL is built for the analytics that happen between a question and an answer. It is not a warehouse-scale BI platform, and some jobs genuinely need one. If you need a governed metrics layer shared across a large organisation, customer-facing embedded dashboards, row-level permissions per tenant, or reporting across a dozen data sources, a tool like Metabase or Looker is the right call, and we would rather tell you that than sell you the wrong thing.
Where ByeSQL wins is the long tail: the hundreds of small, specific questions that are too minor to justify a modelling exercise and too frequent to keep asking a person.
See the full ByeSQL vs Metabase comparison →Common questions
Do I need a data warehouse to use this?
No. ByeSQL queries your operational database directly. There is no pipeline to build, no extract to schedule and no second copy of the data to keep in sync. For a lot of teams the numbers they need are already sitting in the production database.
Is this a replacement for a BI tool?
For the everyday questions that currently queue behind an analyst, yes. For modelled metrics shared across a large organisation, customer-facing embedded analytics or governed reporting on a warehouse, no, and we would rather say so than pretend otherwise.
Who on the team can actually use it?
Anyone who can describe what they want to know. There is no query language, no drag-and-drop builder and no data model to learn. The constraint is knowing what question to ask, not knowing how to express it.
How do we stop people running expensive queries against production?
Every query is read-only, rewritten to carry a row limit of 200 by default and 5,000 at most, and cut off after 20 seconds. The recommended setup also scopes the database user to the tables you want exposed, so analytics access and application access are not the same thing.
Ask your first question in a minute
Free plan, no credit card. Read-only by default.