Search

Search IconIcon to open search

Rill Developer

Last updated by Simon Späti

Rill is a fast dashboards build trust and curiosity. Our fully-managed platform lets you focus on shaping data, not tuning databases and queries. Written in GoLang.

Rill delivers sub-second interactivity because it’s backed by DuckDB, ClickHouse and Druid for our enterprise-grade cloud services. Druid/Clickhouse/OLAP Cubes on Rill Cloud and DuckDB locally.

In other words, Rill is a thick application that comes with its own embedded in-memory OLAP engine ( DuckDB in Rill Developer, and Apache Druid in Rill Cloud). This is the not-so-secret reason why our dashboards offer incredibly high performance.

Came out in 2022

In 2022, Rill Data came out with a new approach. It’s metrics local and metrics first. You define your measures and dimensions as code. You can also define them within the tool, but it always stores them as YAML. Also, the analysis uses DuckDB to analyze ultra-fast and you can see your data in an “engaged” matter out of the box, without the need to create tons of dashboards beforehand. Rill makes you exploring your data very easy.

Rill is a single command line BI tool. That gives it some nice features to quickly run up and dashboard a single file. All other tools are too heavy for quickly spinning up. Also, Rill Data has a YAML approach to define KPIs, so you can essentially check in all your dashboards and have CI/CD on top of it, unlike other dashboards.

# History

The company behind it is Rill Data Company with the founder Michael Driscoll, also founder of Metamarkets, the initial company behind Druid.

As of 2022-08-05 they announced 12 mio funding and want to be a Business Intelligence tool. Rill Data Company wants to rethink BI dashboards with embedded database and instant UX.

Founded by Michael Driscoll.

# What makes Rill Different?

by Brian Holmes, Rill Application developer:

Aerodynamic data models: Flying fast at scale with DuckDB (DuckCon #5, Seattle, 2024) - YouTube

Tech Stack as of 2023-02-07:

# Pivot Table

They added Pivot Table:

Aerodynamic data models: Flying fast at scale with DuckDB (DuckCon #5, Seattle, 2024) - YouTube

# Features

# Metrics SQL

An example with a metrics view definiton and Metrics SQL on top that is concise, reusable, with built-in security and templating, can look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
type: api
metrics_sql: |
   SELECT store_id, revenue
   FROM sales_metrics

plain_sql:  |
   SELECT store_id, sum(item_price)
   FROM sales_items
   GROUP BY 

metrics_sql: |
  SELECT 
    {{ if .user.admin }}
      publisher,
      domain,
      bid_type,
    {{ end }}
    total_records,
    total_revenue,
    avg_bid_price
  FROM ad_bids_metrics
  WHERE 
    timestamp >= '{{ .args.start_date }}'
    AND timestamp < '{{ .args.end_date }}'
    {{ if hasKey .args "country" }}
      AND country = '{{ .args.country }}'
    {{ end }}
  {{ if .user.admin }}
    HAVING total_revenue > 1000
    GROUP BY publisher, domain, bid_type
  {{ end }}
  ORDER BY total_revenue DESC
  {{ if hasKey .args "limit" }}
    LIMIT {{ .args.limit }}
  {{ else }}
    LIMIT 100
  {{ end }}

The metrics view definition (ad_bids_metrics.yaml) under the hood contains:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
type: metrics_view
model: ad_bids
security:
  access: "{{ .user.email }} NOT LIKE '%@excluded-domain.com'"
  row_filter: "{{ if not .user.admin }} publisher = '{{ .user.publisher }}' {{ end }}"
dimensions:
  - name: publisher
    expression: toUpper(publisher)
  - name: domain
    column: domain
  - name: bid_type
    expression: "CASE WHEN bid_price > 0 THEN 'paid' ELSE 'organic' END"
measures:
  - name: total_records
    expression: COUNT(*)
  - name: total_revenue
    expression: SUM(revenue)
  - name: avg_bid_price
    expression: AVG(bid_price)

Best of Both Worlds. Metrics SQL combines SQL’s precision and expressiveness (exact semantics, no ambiguity), YAML’s reusability and abstraction (define once, reference everywhere), and API capabilities (generate OpenAPI specs automatically for integration).

In a traditional SQL approach we’d have more repetition, verbosity, and would requires manual security implementation such as:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
-- Query 1: Admin user requesting filtered data with date range
SELECT 
  toUpper(publisher) AS publisher,
  domain,
  CASE 
    WHEN bid_price > 0 THEN 'paid'
    ELSE 'organic'
  END AS bid_type,
  COUNT(*) AS total_records,
  SUM(revenue) AS total_revenue,
  AVG(bid_price) AS avg_bid_price
FROM ad_bids
WHERE 
  timestamp >= '2024-01-01' 
  AND timestamp < '2024-02-01'
  AND country = 'US'
  AND user_email NOT LIKE '%@excluded-domain.com'  -- Manual security rule
GROUP BY 
  toUpper(publisher), 
  domain,
  CASE WHEN bid_price > 0 THEN 'paid' ELSE 'organic' END
HAVING SUM(revenue) > 1000
ORDER BY total_revenue DESC
LIMIT 100;

And a separate query for admin user:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
-- Query 2: Non-admin user (no dimensional breakdown, different security rules)
SELECT 
  COUNT(*) AS total_records,
  SUM(revenue) AS total_revenue,
  AVG(bid_price) AS avg_bid_price
FROM ad_bids
WHERE 
  timestamp >= '2024-01-01' 
  AND timestamp < '2024-02-01'
  AND country = 'US'
  AND user_email NOT LIKE '%@excluded-domain.com'  -- Must repeat security rule
  AND publisher = 'partner-xyz';  -- User can only see their own data

Why does this matter for agentic workflows?

With the three pillars of semantics, speed, and stewardship, Metrics SQL enables agents to operate on curated targets with immediate responses for iteration. The semantic definitions in metrics views provide the structured context agents need, while the SQL interface gives them a familiar, precise language to express queries without introducing hallucinations or ambiguity.

Metrics SQL is extending SQL for the semantic layer era - creating a higher-level SQL dialect that operates on business concepts rather than raw database columns, making it the ideal interface for both humans and AI agents.

# Demos

# Latest Announcements

All announcements on Release Notes | Rill.

# Rill v0.73 - Project AI Agent

Rill 0.73 - Project AI Agent | Rill

Introducing AI Agents for Rill
We’ve been working hard over the last couple of months to bring an agentic AI workflow to Rill. Building on our existing MCP (Model Context Protocol) server integration, we’re now introducing project-wide chat in Rill, which is our first interactive agent of many to come.

The project agent helps you quickly analyze data, ask open-ended questions, and have the AI spot patterns and anomalies in your datasets. But it’s not just a chatbot—you always have a dashboard ready to back up any responses from the AI. With just a click, you can augment the AI’s insights with your own knowledge, truly bringing machine and human intelligence together.

# Rill v0.47 (2024-07-17)

  • Create public links to Rill Cloud dashboards, allowing non-Rill users to access a prescribed view of the dashboard (with locked down filters)
  • Create user groups to better manage your users and access to dashboards, which can also be utilized through security policies
  • Rill Developer can now access and serve any files placed in an accessible folder from the root of your project
  • Utilize wildcards within your security policy definitions along with inclusion and exclusion policies in conjunction with each other

# Alternatives

  • Notebook style: Evidence. Also BI as code

# Further Reads


Origin:
References: GitHub
Created 2022-08-05