The data warehouse needs an API layer.

The warehouse has become the place where trusted business data lives, but there still is not a clean way to serve that data to the software that needs it.

I keep running into this problem in different forms, from large enterprises with formal data platforms to startups where one person owns the warehouse and half the operational reporting. The company has done the hard work of getting reliable data into one place. The important definitions have been argued over, and the tables people trust are finally usable.

Then someone needs that data somewhere else, and the clean version of the system starts to fray.

A system outside the warehouse needs a precise slice of that trusted data, from a product surface to an AI agent. The request is usually reasonable, while the available options are usually not.

The warehouse is no longer just for humans reading dashboards.

For a long time, the warehouse mostly served analysts and BI tools, and that world still matters, but it is no longer the whole story.

More and more, warehouse data is being used by software, from internal tools that need one account record to MCP tools that need controlled context.

That creates a different kind of requirement than the one BI tools were built around. A dashboard can tolerate a lot of human interpretation, but software needs a contract that runs from the URL and inputs through authentication, observable failures, and durable ownership.

Most data teams do not have a clean place to put that contract.

Qry is my attempt to make that place. It is a small, focused API layer around trusted warehouse data.

What Qry does.

Qry lets a data team take SQL they already trust and publish it as a secure, read-only API.

You write a query against trusted warehouse logic, from a table to a dbt model or semantic-layer-backed dataset, add typed variables where callers are allowed to filter, and publish the endpoint.

select account_id, account_name, health_score, current_mrr, renewal_date from marts.customer_health where true and account_id = {{ account_id }} and health_score <= {{ max_score }} -- @optional

That can become a read-only endpoint.

GET /customer-health?account_id=acct_123

The caller gets the data product the data team chose to publish, without getting a warehouse login or permission to write arbitrary SQL.

The important part is what Qry does not try to be.

Qry is not meant to be another backend platform or another analytics layer. Those tools already exist, and many of them are good.

Qry is for the narrower moment when someone says, "Can we expose this trusted warehouse data to another system?" and the answer should not require starting a backend project.

The narrowness matters because it keeps the product honest.

The serving layer matters.

A lot of tools can put an API in front of a database, and that is useful, but it is not the whole problem here.

The warehouse is expensive and powerful, and it is not the place I want every downstream request or AI loop to land.

Qry should default to controlled refresh, where the warehouse is used when Qry refreshes an endpoint and API traffic is served from Qry's local serving layer.

That means teams can make clear choices about how each endpoint behaves.

refresh this endpoint every 15 minutes;
allow it to serve stale data for two hours;
cap materialized rows and response size;
return a clear error and log what happened.

This is not about pretending every use case is real time, because most operational data requests are not. They need to be trustworthy and bounded, with freshness that callers can understand.

Why this keeps coming up now.

The modern data stack made the warehouse more useful, from dbt giving teams a way to manage logic to reverse ETL proving that warehouse data belongs in operational workflows.

AI is making the same pressure more obvious. Agents need tools, tools need data, and the easiest version is to give an agent broad access and hope policy and prompt discipline will hold. I do not think that is where careful teams will end up.

Careful teams will want smaller surfaces with approved inputs and narrow outputs, plus a way to say what data a system is allowed to ask for and no more.

That is an API problem as much as it is a data problem, and it is the reason Qry exists.