--- title: "Build Self-Service Analytics Without Replacing Your Data Stack" description: "Governed self-service analytics as an overlay on the warehouse and BI you already run: the read-only pattern, what keeps its authority, and where it fails." canonical: https://datarelix.ai/resources/guides/self-service-analytics-without-replacing-your-stack/ publishDate: 2026-08-13 updatedDate: 2026-08-18 lastVerified: 2026-08-17 --- # Build Self-Service Analytics Without Replacing Your Data Stack **Self-service analytics** fails most often when it is sold as a replacement: a new warehouse, a rebuilt semantic layer, a dashboard migration. The alternative is an **overlay** — leave the stack where it is, connect a **read-only user** to what you already run, and let people ask questions in plain English against live data. Your governed models keep their authority; the overlay absorbs the ad hoc queue that was never going to become a dashboard. ## Where this applies Data and analytics leaders who own a working stack — a warehouse, a transformation layer, a BI tool — and a request queue that keeps growing anyway. Analytics engineers who have been asked to "make the data self-service" and want a design that does not put their models at risk. If you are choosing your first warehouse, this is not your problem yet. ## Why the request queue keeps growing Most **self-service BI** programs are aimed at the wrong target. The dashboards usually work. What does not work is everything that falls outside them: one-off questions, definition checks, "is this number right", a slice nobody anticipated. These arrive as messages, get triaged by an analyst, and turn into a query someone has to write by hand, days after the question was asked. The standard responses both have a structural flaw: | Response | Why it stalls | |---|---| | Build more dashboards | Each anticipated question becomes a maintained asset. The unanticipated ones — the majority — still queue. | | Give everyone SQL access | Shifts the bottleneck to correctness and safety. Someone writes a join that double-counts, or a scan that costs real money. | | Buy a new "self-service" platform | Migration cost is paid up front, and the semantic definitions get rebuilt in a second place where they immediately drift. | ## What the overlay looks like
Diagram of two paths meeting at one warehouse. The upper path — operational sources, transformation layer, warehouse, BI dashboards — is labelled unchanged. The lower path adds a plain-English question going to Datarelix, which reads the same warehouse through a read-only user, with an arrow showing the answer returning alongside its evidence.
The governed path keeps its authority; the ad hoc path reads the same tables through a scoped read-only user.
Four properties make this an overlay rather than a second stack: 1. **It reads, it never writes.** The connection is a read-only user scoped to chosen schemas, and read-only is enforced by parsing every generated statement before execution. The mechanism is set out in [read-only AI analytics](/resources/guides/read-only-ai-analytics/). 2. **It holds no copy of your data.** Queries run against the live warehouse. There is no extract to schedule, reconcile, or explain when it drifts. 3. **It does not own definitions.** Your transformation layer stays the place where "revenue" is defined. The overlay queries the models you already built — which is exactly why it should point at governed marts rather than raw tables. 4. **Every answer carries its query.** An overlay that returns bare numbers cannot be checked. One that returns the SQL, the source tables, the row count, and the runtime lets a reviewer confirm the reading in a glance — the habit described in [how to verify an AI-generated data answer](/resources/guides/verify-ai-data-answers/). ## What stays governed, and what moves | Concern | Stays in your stack | Moves to the overlay | |---|---|---| | Metric definitions | Transformation models, tests, documentation | Nothing — the overlay reads the models | | Scheduled reporting | BI tool, governed dashboards | Nothing | | Access control | Database grants on the read-only user | Nothing — the grant *is* the boundary | | Historical accuracy | Warehouse, snapshots, lineage | Nothing | | Ad hoc questions | — | All of them | | Definition checks | — | "Which table did that come from?" answered instantly | | Exploratory slicing | — | Filters and cuts that never justified a dashboard | Note what is not in the right column: **governance**. The overlay does not introduce a second permissions model. Whatever the read-only user can see is the whole of what anyone can ask about, which means your existing grants remain the enforcement point. ## The scoping decision that determines quality ### Point it at governed marts, not raw tables Connect the overlay to raw operational tables and you will get technically valid answers to the wrong question — `orders` includes cancellations, `users` includes internal test accounts, and no one told the model. Connect it to your **governed marts** and the same question lands on the definitions your team already agreed. ### A practical order of operations 1. **Start with one governed schema**, not the whole warehouse. Analytics marts, not raw ingestion. 2. **Grant `SELECT` only, on that schema only. The PostgreSQL script is in [ask PostgreSQL questions in plain English](/resources/guides/ask-postgresql-questions-in-plain-english/); the Snowflake four-grant version is in [ask Snowflake questions in plain English](/resources/guides/natural-language-analytics-for-snowflake/).** Include future tables where your engine supports it, so new models stay visible without a re-grant. 3. **Add descriptions to the ambiguous columns.** A one-line note on `status` or `amount_type` changes which filter gets written. This is the highest-return input, and it is the subject of [why semantic context matters](/resources/guides/why-semantic-context-matters/). 4. **Ask ten questions you already know the answers to.** Compare, then widen scope. ## What the overlay is, concretely Datarelix is a hosted overlay of exactly this shape. You connect a read-only user to [any engine it supports](/features/#engines-title) following the [connection guides](https://docs.datarelix.ai/guides/connections/), and one connection per scoped schema set is a good default. Answers worth keeping become [dashboards](https://docs.datarelix.ai/guides/dashboards/) that refresh by re-running their stored query, so a useful ad hoc result graduates into a durable one without an analyst rebuilding it. That is the part of the overlay that changes the queue rather than just serving it. ## What an overlay will not fix An overlay inherits your schema's problems. Cryptic column names, undocumented status codes, and tables that only three people know are stale will produce confident answers built on the wrong column — the overlay reads the schema as written. It is also not a governance layer: it does not define metrics, and if your organisation has no agreed definition of revenue, it will compute several. Some work does not belong here at all. Writing data, running migrations, and administering databases are excluded by design. Multi-step modelling with heavy business logic still belongs in your transformation layer, with the overlay querying its outputs. Scheduled, pixel-controlled executive reporting is still a BI tool's job. Rollout has a boundary worth planning around: accounts are isolated, so connections, runs, and dashboards stay with the account that created them ([account isolation](/security/)). Each person connects their own read-only user, and handing an analysis to a teammate means exporting it. Plan limits on questions per month and connections are on the [pricing page](/pricing/). ## Scope and provenance Product statements describe Datarelix as shipped in August 2026; the [security page](/security/) is canonical. The failure modes in that section are drawn from common practice in analytics teams, not from a published study, and are offered as a framing rather than a measured finding. No external benchmarks are cited. ## Try it on one governed schema Try the overlay against one governed schema: follow the [quickstart](https://docs.datarelix.ai/quickstart/) to connect a read-only user, then ask five questions whose answers you can already verify. Datarelix is free for 14 days, no credit card required.