Each one starts the same way: a SQL query you already have, and someone outside your code who needs its result. What differs is who is asking and what they must not see. Each has its own page, with the configuration and the responses it produced.
Data inside your product, for your customers and your staff.
three use casesData that leaves the building, on your terms.
three use casesAccess for everyone who needs it, without handing out the database.
three use casesEvidence for auditors, and operations your platform team recognises.
two use casesCustomers want their own numbers inside your product. Building that usually means an analytics backend with tenant isolation you have to get exactly right. Here, each user signs in with the token your app already issues, and the tenant comes from that token, never from the request.
Read the use case →A frontend needs six queries from three databases. That is six endpoints, three drivers and one more service to keep alive. Or it is six saved queries, one key with JWT sign-in for your app's users, and CORS.
Read the use case →Sometimes the job is putting data in: a partner submitting orders, a form filing a request, a support lead correcting a record. Writing is off by default at every level, and you open one query, for one caller, and nothing else.
Read the use case →A customer wants their orders. The usual answer is a bespoke endpoint, an auth middleware and a quarter of review time. The alternative is a scoped key that can call exactly one saved query, written for their rows.
Read the use case →Every night a partner needs yesterday's changes as Parquet in their S3 bucket. Writing that job means credentials, retries, a watermark and a place to see when it failed. A saved export is all of those.
A wall display or a client that reacts when a query runs. GET /events streams each run as it completes, per key if you want, fanned out across instances by the events server.
Ten teams want data from the warehouse. Shared database passwords leak, and routing every request through the data team as a ticket doesn't scale. Publish saved queries in collections instead, give each team a role, and let people find what they can use.
Read the use case →The lake has the data; the people who need it have a browser and curl. A DuckDB connection pointed at a prefix makes each file a view, locked to the paths you list, with no copy and no warehouse.
The core system runs on Oracle, SQL Server or DB2, and nobody wants to touch it. Generic JDBC loads the vendor's own driver, so that data can be served through saved queries with the same keys, limits, quotas and audit as any other connection.
Read the use case →An auditor asks who changed which grant, and how you know the record wasn't edited. A questionnaire asks where personal data goes and which cryptography protects it. The answers are the product's own behaviour, each one checkable.
Read the use case →The platform team wants it installed with Helm, changed through a pull request, and holding no database password of its own. Each of those is a setting, not a project.
Read the use case →The example APIs ship with a generated database and one scoped key per scenario, so you can try each of these in a few minutes without connecting anything of your own.