AVAILABLE NOW · OPEN SOURCE

Big ideas.
Little footprint.

A semantic layer built on Ossie,
shipped with your app.

Play with it in your browser or start in Claude ↓

PLAYGROUND · NO SIGN-UP

See RooQL work before you install anything.

Ask a question about a made-up coffee shop. RooQL compiles it from one Ossie model into SQL, and DuckDB runs that SQL right in your browser tab. Every chart shows the query that made it.

Open the playground

1 · You ask

{ "metrics": ["revenue"],
  "dimensions": ["customers.segment"] }

2 · RooQL compiles it from the model

SELECT "t1"."SEGMENT" AS "d0",
  SUM(CASE WHEN "t0"."STATUS" <> 'cancelled' …) AS "m0"
FROM "ORDERS" AS "t0"
LEFT JOIN "CUSTOMERS" AS "t1" ON …

3 · DuckDB runs it in your tab

START IN CLAUDE

Ship your first semantic app in seconds.

Paste a prompt into Claude. Start a new artifact where every number is compiled from one Ossie model, or bring two artifacts that disagree and make them match. Nothing to install or host.

Open source and free to use
Compiles to Snowflake, DuckDB and BigQuery SQL
About 16 KB gzipped, no dependencies

Build me a Claude artifact that answers questions about my data using RooQL, the open-source semantic layer built on Apache Ossie.

1. Read https://rooql.com/llms.txt and follow it.
2. Define the metrics in one small Ossie model, with a description for each. If I haven't shared my tables yet, ask me which table and metrics to use.
3. Inline the RooQL compiler from https://rooql.com/rooql.js. Compile every query from the model instead of writing SQL by hand, and show the generated SQL under each chart.
4. Run the SQL through my warehouse connector.

Here are two Claude artifacts that show different numbers for revenue per day: [paste or link the first] and [paste or link the second]. Use RooQL, the open-source semantic layer built on Apache Ossie, to make them agree.

1. Read https://rooql.com/llms.txt and follow it.
2. Work out the definition each artifact uses, and explain exactly why their numbers differ.
3. Ask me which definition is right, or propose one.
4. Write the agreed definition as one Ossie model, and rebuild both artifacts so every number is compiled from it with RooQL. Show the generated SQL under each chart.
5. Keep the model in one place both artifacts read at runtime, such as a table in my warehouse that my connector can query, so the next definition change reaches both.

WHEN DASHBOARDS DISAGREE

Why don't these numbers match?

Sales says yesterday's revenue was €41k and finance says €38k. Both built their own artifact, and each one wrote its own SQL.

“The DuckDB of semantic layers.”

RooQL is how the data team settles it.

Give Claude both artifacts and your definition. It works out why they disagree, whether that's refunds, ship date instead of order date, or test orders left in. Then it writes the agreed definition into an Ossie model and rebuilds both artifacts so every number comes from it.

Keep that model in one place your artifacts read from, such as a table in your warehouse, and the next change to a definition reaches all of them. Give your team the same starting prompt, and new artifacts use the model from day one. You get one source of truth with no infrastructure to manage.

Take a peek under the pouch

UNDER THE POUCH

One question, from your model to the chart.

Follow “revenue by country” through a Claude artifact. Then change what revenue means and watch the change travel.

Revenue is

Your team

Inside the Claude artifact

Your warehouse

semantic_model.jsonApache Ossie

"metrics": [{
  "name": "revenue",
  "expression":
  "SUM(orders.amount)"
}]

The artifact asks unchanged

compile({
  metrics: ["revenue"],
  dimensions: ["orders.country"],
})

RooQL compiles

About 16 KB gzipped, bundled in the artifact. No server.

compiled SQL · Snowflake

SELECT
  "t0"."COUNTRY" AS "d0",
  SUM("t0"."AMOUNT") AS "m0"
FROM "AGENT_DEMO"."PUBLIC"."ROOQL_ORDERS" AS "t0"
WHERE "t0"."STATUS" = 'completed'
GROUP BY "t0"."COUNTRY"

The viewer’s connector

Their own sign-in and permissions. No keys in the artifact.

Snowflake runs it

Your warehouse does the work and returns rows.

Revenue by country

GB: 150
FR: 100
Unknown: 40

Define. Revenue is written down once, in an open Apache Ossie model your team keeps.
Ask. The artifact asks for metrics by name. There is no SQL in its code.
Compile. RooQL, inside the artifact, turns the request into SQL for your warehouse.
Run. The SQL goes through the viewer’s own connector to Snowflake.
Draw. Rows come back and the chart renders.

The SQL, results and model hashes are real RooQL output, checked against Snowflake. The model is shortened for the page.

BUILT ON AN OPEN STANDARD

Built on
Apache Ossie.

Your business definitions live in an open specification, not another proprietary modelling language.

Your definitions stay in an open standard, so they aren't locked into any product, ours included.

Apache Ossie (incubating) is an open YAML/JSON specification for semantic models: datasets, fields, metrics and relationships. RooQL reads your Ossie model as it is and compiles metric queries straight into warehouse SQL.

No second model to maintain. No definitions drifting apart.

Read about Apache Ossie

GOOD THINGS START SMALL

Stay in the loop.

RooQL is out now. Get release notes as it grows.

A FEW SMALL DETAILS

Curious?
Good.

Can I try RooQL today?

Yes. Copy the Claude prompt near the top of this page, or add the compiler to your own app. RooQL is open source and free to use.

Who is RooQL for?

Teams building data apps, dashboards and Claude artifacts who want every one of them to use the same metric definitions, without running a semantic layer service.

What can it do today?

Metrics that sum, count, average or count distinct across a star schema: a fact table joined out to its lookup tables, grouped by any field or by month, quarter or year, and filtered by values, ranges and lists. It compiles to Snowflake, DuckDB and BigQuery SQL. Queries that would double-count, or that need two fact tables at once, fail with a clear error instead of a wrong number. Read the docs.

Is it a database?

No. RooQL compiles metric queries into SQL. Your warehouse runs the SQL, and your app's existing connection handles access and permissions.

Why a kangaroo?

A kangaroo carries what matters in its pouch. We like the idea of your app carrying a small semantic compiler wherever it goes. Also, excellent ears.

Big ideas.Little footprint.