Metabase | Business Intelligence, Dashboards, and Data Visualization

Winners of the Metabase AI Hackathon

Wed, 13 May 2026 00:00:00 +0000

We ran the Metabase AI Hackathon to celebrate every AI feature in Metabase going open source.

The submissions were genuinely fun to go through: analytics agents, new products, an entire API with machine learning, a couple of things that made us laugh, a couple that made us think “oh, that’s actually clever.” Picking two was harder than we expected.

Here are the winners:

Meta Chess, by Marat Surmashev

A live dashboard where Claude and Codex play chess against each other, with Metabase as the entire game platform, not a passive viewer.

This one uses two of our newest features in tandem. The agents sync through the MCP server: read the board state, check whose turn it is, and see the opponent’s last move. What spectators watching the dashboard see and what the agents see is the same source of truth.

The dashboard itself is built with file-based development: the live chessboard, the last-move highlight, and the move history are all Metabase YAML cards shipped through the serialization v2 API.

We picked this one because it shows off two of our newest features doing something neither was designed for. The MCP server isn’t just feeding one agent, it’s the message bus between two. File-based development isn’t just for version control, it’s how the whole dashboard ships as code. Turns out a Metabase dashboard can be a chessboard, a referee, and a livestream all at once. Who knew.

See the project · GitHub repo

Claude’s Advice, by Owais Mumtaz

A nightly Cowork task that reads the last 60 days of Owais’s personal fitness data via our MCP server, reviews his goals, and writes back to his dashboard as a chart titled “Claude’s Advice.”

Calories, macros, workouts, weight — all facts and dimensions in a personal database, with a semantic layer and predefined metrics. When Metabase 60 dropped MCP support, Owais realized Claude could use what he’d already built. The data was already mapped. Based on his current plateau, the chart told him to refeed this weekend: 3,000 calories, 400g carbs, hit legs hard, check the scale Wednesday.

We picked this one because it’s small, useful, and real. No big architecture diagram, no fancy multi-agent setup. Just one nightly task, one trusted semantic layer, and one chart that tells Owais what to do tomorrow. The kind of project that a lot of people could build for themselves this weekend… and probably should.

Watch Owais’s walking through the project

Two mechanical keyboards are on their way to Marat and Owais. Thanks to everyone who participated.

If you haven’t tried AI in Metabase yet, you don’t need a hackathon to start, go build something and tag us, we read everything

Improving the performance of the popular Clojure development tool clojure-lsp

Tue, 12 May 2026 00:00:00 +0000

Development tools can sometimes struggle when dealing with large codebases. This gives performance nerds like me a reason to investigate. In this case, I ended up cutting clojure-lsp’s startup time in half and memory allocation by two thirds.

Part 1: The mystery of heap headroom

Devs working on Metabase were complaining about LSP taking too long to boot, so I wondered how long it could be. A few seconds? Half a minute? Imagine my surprise when I saw this:

(time (clojure-lsp.api/analyze-project-only!
  {:project-root (clojure.java.io/file "/path/to/metabase")}))

"Elapsed time: 178981.918417 msecs"

Three minutes is a long time.

The first suspect was heap size. There is a good rule of a thumb: if some process in Clojure (or any JDK language) takes longer to complete than anticipated, or doesn’t finish at all, you should check the heap.

I used VisualVM to inspect our Clojure process and ran the benchmarking command, which gave us something like this:

What’s going on here? My laptop has 16 GB of RAM. By default, Java will take 25% of total RAM as the maximum heap size for the process. In my case, that means 4GB max heap, as you see in the screenshot. Clojure-lsp’s analysis fills up the heap with more and more unfreeable data, meaning objects that don’t get garbage-collected. The heap headroom (the amount of free heap space after garbage collection) becomes smaller and smaller, which means garbage collection has to run more often, to the point where a GC run has to start up before the last run can complete.

Giving more heap space to the process by adding an -J-Xmx6g argument to the REPL command line shows a different picture:

(time (clojure-lsp.api/analyze-project-only!
  {:project-root (clojure.java.io/file "/path/to/metabase")}))

"Elapsed time: 115370.613041 msecs"

Still almost two minutes, but we’ve shaved off a minute by just giving the process more space to breathe. The heap plot shows that “used heap” no longer hugs the “max heap” threshold so tightly, so GCs trigger less often.

Part 2: Profiling and optimizations

My next step was to use clj-async-profiler to obtain a flamegraph of the benchmark above. I took an allocation profile instead of a regular CPU profile because I’ve found that optimizing allocation hotspots results in roughly the same execution time savings, but allocation profiles have less variance and skew.

(clj-async-profiler.core/profile {:event :alloc}
  (clojure-lsp.api/analyze-project-only! {:project-root (clojure.java.io/file "/path/to/metabase")}))

Allocation flamegraph before improvements. Click to open.

A flamegraph is a good way to spot the hot code in stack traces (see this tutorial for more on flamegraphs). On the Y axis, you have stacks that grow from bottom to top. The position of the frame signifies which function calls which, and the height of the flamegraph shows the stack’s depth (which usually doesn’t matter).

On the X-axis, the width of a frame shows how much total time each function call takes (or, in this case, the number of allocations of a particular object class). The coordinate of the frame on the X-axis doesn’t imply its position in time; in fact, the X-axis coordinate doesn’t mean anything (just its width).

Looking at the flamegraph, most of clojure-lsp’s initialization is taken up by clj-kondo. If you search in the embedded graph for “kondo,” you’ll find that 95.41% of all frames match, meaning almost all work is kondo-related.

After massaging the flamegraph and pruning irrelevant pieces, I found several significant inefficiencies and solutions for them.

deep-merge

The deep-merge function is similar to clojure.core/merge, but when deep-merge merges maps, it also merges values with duplicate keys in those maps. There were a few things to be improved here:

If the value in the resulting map doesn’t change, don’t perform the assoc operation. So if m already has {:k1 someval}, we can skip (assoc m :k1 someval).
Before merging two sets, check if they’re equal. If they are, there’s no need to merge them; just return one of them.
Only use Clojure transients for large collections, as transients bear some static upfront overhead, which can be less efficient than using simple vectors for small collections.

rewrite-clj improvements

rewrite-clj is a library that Kondo and LSP use to read and parse Clojure. I’ve applied several optimizations to it, but the most impactful change was dropping a dynamic variable on a hot path.

In Clojure, dynamic variables (usually *earmuffed*) allow for passing “hidden” context to other functions instead of adding explicit arguments. In a sense, this hidden context is global state, but restricted to stack scope. A simple example:

(def ^:dynamic *honorific* nil)

(defn hello [name]
  (if *honorific*
    (str *honorific* " " name)
    name))

(hello "John")
=> "John"

(binding [*honorific* "Mrs."]
  (hello "Smith"))
=> "Mrs. Smith"

Here, having *honorific* as a dynamic variable saved us the trouble of adding another argument to hello. But setting a value for a dynamic variable with binding involves creating a new hashmap every time, and assoc-ing the value to it. That means allocations and spent cycles. So, if you care about the performance of a particular hot function, make sure to pass all arguments explicitly.

Better memoization

Clojure kindly provides the clojure.core/memoize function, which caches the outputs of a function for the given inputs.memoize’s implementation, however, is quite simplistic and unoptimized:

To accept functions of any arity, clojure.core/memoize uses a list of arguments as the cache key. Rolling arguments into the list triggers additional allocations.
memoize also uses find to look up the value for the key in the cache. When the map contains the key, find returns a key-value pair, a MapEntry object, which again needs to be allocated in the heap.

Because clj-kondo only needs memoization for one- and two-argument functions, a more specialized implementation was warranted. For a single argument, the code is straightforward. For two arguments, the main trick is to structure the cache as a nested map {arg1 {arg2 cached-value}} instead of {[arg1 arg2] cached-value}. Nesting the map avoids wrapping arguments into a vector during the lookup.

Part 3: Measuring total allocations

I proposed each optimization as a separate PR to clj-kondo, because I thought it would be helpful for the maintainer, the venerable Michiel Borkent, to see the impact of each optimization. The timing differences for each improvement separately were too flaky to observe a meaningful difference, so I came up with another metric: the total number of allocated bytes during the benchmark.

The following script does the work of hooking into GC events and captures how many bytes were freed each time. In the end, we add up all those bytes to calculate the total allocated value.

(import
 '[com.sun.management GarbageCollectionNotificationInfo GcInfo]
 '[javax.management NotificationEmitter]
 '[java.lang.management ManagementFactory MemoryUsage]
 '[javax.management NotificationListener]
 '[javax.management.openmbean CompositeData])

(def memory-bean (ManagementFactory/getMemoryMXBean))
(def gc-collections (atom []))

(defn calc-freed
  "Return the number of bytes reclaimed by a given GC run."
  [^GcInfo gc-info]
  (let [before (.getMemoryUsageBeforeGc gc-info)
        after  (.getMemoryUsageAfterGc gc-info)]
    (reduce (fn [total pool]
              (let [used-before (.getUsed ^MemoryUsage (get before pool))
                    used-after  (.getUsed ^MemoryUsage (get after pool))]
                (if (> used-before used-after)
                  (+ total (- used-before used-after))
                  total)))
            0
            (keys before))))

(defn install-gc-listener!
  "Add a hook that runs on every GC invocation to intercept and remember how
  much heap space the GC freed."
  []
  (doseq [gc-bean (ManagementFactory/getGarbageCollectorMXBeans)]
    (.addNotificationListener
     ^NotificationEmitter gc-bean
     (reify NotificationListener
       (handleNotification [_ notification _]
         (when (= (.getType notification)
                  GarbageCollectionNotificationInfo/GARBAGE_COLLECTION_NOTIFICATION)
           (let [info (GarbageCollectionNotificationInfo/from
                       ^CompositeData (.getUserData notification))
                 gc-info (.getGcInfo info)
                 freed   (calc-freed gc-info)]
             (swap! gc-collections conj freed)))))
     nil nil)))

(install-gc-listener!)

(def used-heap-before (.getUsed (.getHeapMemoryUsage memory-bean)))

(time (clojure-lsp.api/analyze-project-only! {:project-root (clojure.java.io/file "/path/to/metabase")}))

(defn print-allocation-stats []
  (let [used-heap-after (.getUsed (.getHeapMemoryUsage memory-bean))
        total-allocated (+ (reduce + @gc-collections)
                           used-heap-after
                           (- used-heap-before))]
    (println (format "Allocation stats: %s GC collections, allocated %.1fGB"
                     (count @gc-collections)
                     (double (/ total-allocated 1e9))))))

(print-allocation-stats)

With this script, I got the following numbers before and after the applied optimizations:

;; Before
"Elapsed time: 89335.263292 msecs"
Allocation stats: 245 GC collections, allocated 145.0GB

;; After
"Elapsed time: 46784.39225 msecs"
Allocation stats: 117 GC collections, allocated 51.6GB

We see a 2x improvement in the elapsed time and almost 3x reduction of the number of bytes allocated on the heap.

To see where exactly the improvements manifested in the code, I took a second allocation profile using clj-async-profiler to generate a diffgraph.

Allocation diffgraph after improvements. Click to open.

A diffraph is a type of flamegraph that combines two profiles and shows differences between them. Color represents the direction and intensity of change. Blue frames mean that the second profile contains fewer samples for that code path (which means faster, fewer allocations, etc.). Red frames show more samples than before.

Highlighting the diffgraph’s base shows that we reduced allocations by ~66% (which matches the benchmark results above). If you scroll up to stacks of more saturated blue, you’ll see which parts of the code were the most affected. For instance, clj-kondo.impl.analyzer.namespace/analyze-ns-decl has almost completely disappeared from the profile (-96% allocations on that codepath), clj-kondo.impl.rewrite-clj.parser.core/parse-delim performs 93% fewer allocations than before, and so on. When you see a sea of blue on the diffgraph, you know you are doing something right.

Conclusions

Being able to do something in a development tool is the main part, but speed and ergonomics matter just as much. A tool that is “almost instant” when employed in a small project may become unwieldy in an industrial-scale one like the Metabase codebase.

We significantly improved clojure-lsp’s initialization time and memory pressure. Eric Dallo, the maintainer of clojure-lsp, has kindly provided his own benchmark results and analysis of the optimizations, and has independently confirmed the speed-ups on codebases comparable to Metabase. Our proposed changes are already merged, and will ship in the new release of clojure-lsp.

There is still plenty to be done to improve the clojure-lsp experience. The server still keeps a weighty amount of heap when loaded (around 2-3 GB) and there are probably a lot more opportunities to reduce this number. But that’s a story for another blog post.

How we built ten custom subagents to tame a 500K-line Clojure codebase

Mon, 27 Apr 2026 00:00:00 +0000

Metabase’s backend is big. We’re talking 500K lines of Clojure code spread across a query processor, permissions system, numerous database drivers, a notification pipeline, serialization layer, search engine, and more. And like all big codebases, each subsystem has its own idioms, gotchas, and “you just have to know” moments.

I’ve been using Claude Code for backend work on Metabase for a while now. It’s pretty good. But overloads Claude’s context window quickly. Every time Claude needs to understand a subsystem, it explores, greps, and reads files. All of that exploration eats your context window. Even when Claude spawns subagents, they will need to do a lot of extra work to get up to speed on the domain.

I built some custom subagents to fix this.

What are subagents and why did I make ten of them?

Metabase’s backend has natural domain boundaries. The query processor is a 68-stage middleware pipeline that compiles MBQL (the Metabase Query Language) to SQL across 18 database dialects. The permissions system is a multi-granularity graph that handles row-level security, database routing, and connection impersonation. The notification system renders charts to images inside a JVM. These are different worlds.

A single generalist Claude session can navigate any of them, but it pays a context tax every time it switches domains. Subagents eliminate that tax by front-loading domain knowledge into the system prompt.

Subagents are a Claude Code feature that lets you define specialized AI assistants as markdown files. They each get their own context window, system prompt, memory, toolkit, and model selection.

I used Claude to write the “job descriptions” for each agent. I described the domain and what an expert would know, and Claude helped me flesh out the codebase locations, investigation patterns, caveats, and testing strategies. Each agent ended up being roughly 2,000-3,000 tokens worth (about 150 lines of markdown) of dense, useful context that can’t be easily inferred from the code.

What’s inside an agent file?

Each agent is a markdown file that follows the same pattern of, domain knowledge → codebase locations → investigation approach → caveats → testing strategies. It’s a “here’s everything you need to be useful in this corner of the codebase” document.

Every file starts with YAML frontmatter:

---
name: mbql-expert
description: "Use this agent when working on Metabase's
  query processor, MBQL query language, SQL compilation..."
model: opus
memory: user
---

The description tells Claude when to delegate. The model picks which Claude model the subagent uses. And memory: user gives the agent a persistent directory at ~/.claude/agent-memory/mbql-expert/ where it records learnings across sessions.

The body of the file is the actual domain knowledge. Here’s a trimmed look at what the mbql-expert knows:

You are a senior backend engineer with deep expertise
in Metabase's query processor (QP), MBQL query language,
and the entire query compilation pipeline.

## Your Domain Knowledge

### The Query Processor Pipeline
You understand the QP's ring-style middleware pipeline
with its four phases:

- **Around middleware** (3 layers)
- **Preprocessing** (44 layers) — source card resolution,
  parameter substitution, join resolution, temporal bucketing...
- **Execution** (8 layers) — caching, permissions, result metadata
- **Postprocessing** (13 layers) — formatting, timezone conversion...

### Key Codebase Locations
- `src/metabase/query_processor/` — QP core
- `src/metabase/driver/sql/` — SQL driver base
- `modules/drivers/` — database-specific drivers

### Important Caveats
- Middleware ordering matters. Adding middleware in the wrong
  position causes subtle bugs.
- A fix at the `:sql` level affects ALL SQL databases.
- BigQuery is not standard SQL. Oracle has no BOOLEAN type.

### REPL-Driven Development
Use `clj-nrepl-eval` to evaluate middleware transformations
step by step...

The ten subagents

I used Claude to help with defining these specific agents, framed as “job descriptions” like you’d post online (but specific to each section of our code). Our module system and namespace documentation help here, but I reviewed it to make sure it was reasonable.

Agent	Domain
mbql-expert	Query processor, MBQL language, SQL compilation, middleware pipeline, HoneySQL, streaming execution
permissions-expert	Access control, sandboxing, SSO (SAML/OIDC/LDAP), connection impersonation, embedding security
platform-expert	App database, HTTP server, API framework, settings system, migrations, Quartz scheduling
enterprise-expert	Serialization, SCIM provisioning, multi-tenancy, database routing, dependency tracking
content-expert	Collections, dashboards, cards, models, metrics, revisions, parameter mappings
notifications-expert	Dashboard subscriptions, alerts, email/Slack rendering, chart image generation
drivers-and-sync	Database drivers, metadata sync, fingerprinting, type mapping, connection management
search-expert	Search indexing, scoring/ranking, X-ray auto-analysis, semantic search
ai-expert	Metabot v3, LLM tool calling, context engineering, SQL generation
transforms-expert	Data actions, CSV uploads, transform pipeline, workspace management, model persistence

I’ve made all ten markdown files available for you to take a look at.

My Favorite: mbql-expert

The query processor is the heart of Metabase and the hardest thing to navigate. It’s a 68-stage middleware pipeline where a query enters as MBQL, gets rewritten 44 times during preprocessing, compiled to SQL via HoneySQL, executed, and then post-processed through 13 more stages. Oh, and some middleware runs twice because later stages can introduce structure that earlier stages need to process again. Query processing is a complex problem, especially when dealing with many different databases.

The mbql-expert already knows all of this. When I say “trace why this nested query with joins produces wrong results on Redshift,” it doesn’t start by grepping. It reasons about which middleware stages touch join aliases, checks Redshift-specific driver overrides, and examines the HoneySQL output. That’s the difference between a generalist exploring and a specialist investigating.

How I actually use the agents

The nice thing is you don’t need special syntax. Just mention the agent:

“Bounce this off the enterprise expert — will this serialization change break round-trip import/export?”
“Ask the permissions expert how row-and-column security interacts with joined tables.”
“Have the mbql expert review this HoneySQL compilation change.”

Claude reads the intent and delegates work to the right agent. If you want to be explicit, you can also @-mention agents directly.

One useful pattern for explicit mentions: launching multiple agents in parallel. When reviewing a change that touches the query processor and permissions, I’ll ask Claude to have both experts weigh in simultaneously. Each expert investigates in its own context, and the results come back without cross-contaminating each other’s exploration.

Tips for making your own subagents

The pattern I’ve described works for any large codebase with distinct subsystems. See Claude’s subagent documentation for the details on how to structure the files.

Here are a few things that worked for me:

Have Claude help you write the agents: describe the domain and what an expert would know, and iterate on the system prompt together. (That’s how I built these.)
Spend more time iterating on the description than the actual system prompts. The 2-3 sentence description in the frontmatter of each Markdown file is what Claude reads to decide when to delegate. A description that says “use for query processor work” is too vague, Claude won’t reliably match it. You want specific trigger words: “MBQL query language, SQL compilation, middleware pipeline, HoneySQL, streaming execution.” Think of it as writing a routing rule, not a job title.
I include codebase locations in every agent, but the most durable content is the investigation patterns and caveats. Directories get renamed but the fact that “some middleware runs twice because later stages introduce structure that earlier stages need to re-process” isn’t going away anytime soon.

Personal agents live in ~/.claude/agents/, and project-local agents go in .claude/agents/.

Now go build some agents!

Metabase AI Hackathon

Tue, 21 Apr 2026 00:00:00 +0000

Show us what you can build with the new AI tools and get the chance to win a Metabase mechanical keyboard.

Metabase now ships an MCP server, an Agent API, and Metabot in Slack: three different ways to plug your analytics into whatever agent or workflow you’re building. All in open source, which means the tools are yours, the semantic layer is yours, what you build on top of them is up to you. So we figured: let’s see what the community can build.

Join the hackathon

To enter:

Build something using the AI tools listed below. Solo or with a team.
Write it up — a social post, blog post, short video, or repo with a good README. Something that shows off what’ve built.
Submit your entry by sharing it on X or LinkedIn, tag @metabase, and use #MetabaseAI.
Submit by Tuesday 05/05/2026.

Build whatever you like. Analytics agents, dashboards that summarize themselves, something weird we didn’t think of — all fair game. If it uses one of our AI tools somewhere in the loop, it counts.

Get inspired by this demo of a voice-powered agent built with the Metabase agent API. Ask a question out loud, get an answer grounded in your actual data. Watch the full demo

The AI tools to use

Your submission must use at least one of the following tools:

Metabase MCP server — plug Metabase into Claude, Cursor, or any MCP client. Ask your data questions from your editor.
Agent API — build your own agent on top of your Metabase’s semantic layer.
File-based development - let an AI agent create and edit Metabase content serialized as YAML files.
Metabot in Slack — point Metabot at a Slack channel and let your team query data where they already argue about it.

All AI features are available for everyone with Metabase 60. If you’re on an earlier version, please upgrade. If you’re on Cloud, we’re rolling 60 out soon (email help@metabase.com if you want to upgrade now).

Prizes

We’re picking two winners. Each one gets:

A Metabase mechanical keyboard (the good kind, not the kind that clacks at you judgmentally)
A feature on our blog
A shout-out across our socials

Timeline

Hackathon opens: Tuesday, April 21st
Submissions close: Tuesday, May 5th
Winners announced: Thursday, May 7th

Have fun!

Meet Repro-Bot, our GitHub issue triage agent

Fri, 10 Apr 2026 00:00:00 +0000

Reproducing bug reports is one of the most time-consuming parts of maintaining an open source project. We built an AI agent called Repro-Bot to help us with this task. In this post, we’re sharing how we built it and show you how you can build your own. If you want to skip ahead and check out our code, take a look at the Repro-Bot repo!

Repro-Bot automates the boring parts

Think about how you, a human person, would reproduce a bug report:

Set up an environment identical (or at least similar) to what the reporter has.
Follow the steps provided in the issue.
If you can reproduce the bug:
- Write a test for the bug
- Fix it
If you can’t reproduce, think through why:
- Is there information missing?
- Are there any hidden dependencies?
- Did anything change recently?
- etc

This process is a mix of judgement calls (like ”fix it,” or what constitutes a relevant change), and chores like setting up the environment, following the steps, and asking the same questions over and over.

Repro-Bot automates the boring parts and gets us started on fixing the issue.

Results: repro steps, findings, possible root cause

As Repro-Bot attempts to repro an issue, it generates a report with its findings, a pointer to where in the code the bug probably occurs, etc.. For example, here is the first part of its output for this issue about disappearing percentages on some pie charts.

This information helps us respond to the person who reported the issue faster and get more details from them while it’s still fresh in their mind. We’ve also cleared out a number of issues from our backlog that Repro-Bot confirmed we had already fixed.

Of course, Repro-Bot isn’t infallible. Sometimes it can’t repro an issue. Sometimes it thinks it has reproduced a bug when it hasn’t. But even in those cases, Repro-Bot’s reports are still valuable. They give us hints and chronicle dead-ends, both of which save devs time getting to the root cause.

How Repro-Bot works, and how to build your own

The details of Repro-Bot are quite specific to Metabase, but we’ll walk you through its inner workings so you can build a similar agent for your own codebase and development setup. You can also fork our repo and adapt it to your workflow.

Repro-Bot needs to be able to perform these tasks:

Parse and understand issues
Spin up a test environment
Work through reproduction steps
Write tests
Write a report
Clean up and self-review

Here’s how we approached each one.

Parsing issues tells the LLM what you, a developer, are looking for when you analyze the issue yourself. For example, for Metabase, we need information about the Metabase version, the application database, the data warehouse. We also triage the issue as backend-focused or frontend-focussed to guide which tools should the agent use for reproduction.
Spinning up a test environment is very specific to your codebase and tools, of course. At Metabase, we use Playwright for browser automation, filling forms, and taking screenshots. Repro-Bot spins up an environment in the same way that a developer would, and uses REPL access to the instance.
To work through the reproduction steps, we wrote a skill that gives code recipes for common actions we see in reported reproduction steps, like inspecting a table or creating a query. We also wrote down some of the “folklore” domain knowledge around some features (like for example that there are two different ways to make a pivot table with two different code paths). Repro-Bot uses the reproduction steps that it previously extracted from the issue, invokes the tools based on the “triage” into backend/frontend, and uses the recipes for those tools to run through the repro steps. It then evaluates what was tested and if its results match the reported behavior. If the agent can’t determine whether the issue was reproduced, it tries again (but no more than three times total).
If the agent reproduces the issue, it writes a failing test so that a developer can have something to test against when they’re fixing the issue. We give some directions on the kind of tests we write for our code and troubleshooting common issues, but since the agent already has full access to the codebase, it can learn a lot from just analyzing existing tests.
Write a report and post to Linear. This provides the bot with a detailed outline for the report (as you saw in the previous section), as well as instructions for how to post to Linear, and how to prevent the internal report from getting synced back to GitHub.
Finally, cleanup and self-review. After each run, Repro-Bot reviews the notes from this and previous runs to make concrete suggestions for improvements, for example to address tool errors, close any knowledge gaps it found, document new tools it might need, etc.

Integrating Repro-Bot into the workflow

We use GitHub to collect reported bugs, and Linear to manage development work. To run Repro-Bot, a human tags a bug on GitHub with .Run Repro-Bot, which triggers a GitHub action that runs the workflow described above.

Running the bot is not an automated task by design: a human in the loop is essential to prevent injection attacks. Most issues come from our public GitHub issues, so it would be trivial for somebody to poison context. To guard against this, we sandbox the agent and limit its permissions. We also require a human to review issues before running it to make sure there is nothing suspicious in the issue.

We intentionally did not ask Repro-Bot to fix the issue. We had initially wanted to make a more end-to-end bot that could do it all, but that wider scope opened up a number of wrong paths the bot could go down. Keeping the agent’s purview limited keeps its output manageable, and we can always introduce more automation downstream.

What we learned

We think that Repro-Bot is an interesting approach to using LLMs and AI tooling for software development, because it’s not about code generation. Our Repro-Bot repo is very specific to our setup, but with the code as a starting point and the description above, you can build your own.

Repro-Bot has become part of our daily development work, and continues to save us time. We hope that it inspires others to build (and share!) similar tools for themselves.

Meet Data Studio: tools to curate your semantic layer in Metabase

Tue, 10 Mar 2026 00:00:00 +0000

Metabase has grown a lot over the past few years. We’ve added a bunch of tools to help people stay on top of their analytics as things scale.

Eventually, it became clear these tools needed their own home.

Today, we’re introducing Metabase Data Studio, a place where teams can shape their data and define shared metrics.

Analytics starts simple. Then it gets… less simple

One goal at Metabase has always been to help non-technical people answer questions with data. And at first, that’s easy. You connect Metabase to your database, build a few dashboards, and things feel straightforward. But over time, cracks in the data model inevitably start to show.

People aren’t sure which tables to use, dashboard loading times get annoying, and there are three different queries that say “ARR”. AIs don’t stand a chance sifting through this stuff.

Data Studio has all the tools you need to clean up the mess

Data Studio lets teams transform raw tables into analytics-ready datasets. You can define reusable metrics (like MRR) and segments (like Active Customers) that everyone (including AI!) can trust when building dashboards and questions.

Data Studio lives in Metabase: no extra tools, no duplicate work, no workflow overhauls, just publish and share instantly. You can start small and grow into it naturally as analytics becomes more shared and harder to change.

The tools in the toolbox

The first version of Data Studio ships with the following tools:

Library: A curated space for your organization’s most trusted analytics content—tables, metrics, and SQL snippets that your data team recommends.
Data structure: Add table metadata to make tables easier to work with.
Glossary: Define terms relevant to your business, both for people and agents trying to understand your data.
Dependency graph: A visual map of how your content connects, so you can understand the impact of changes before you make them.
Dependency diagnostics: See which items have broken dependencies, or that aren’t used.
Transforms: Wrangle your data in Metabase, write the query results back to your database, and reuse them in Metabase as sources for new queries.

And we have more to come, so stay tuned.

Open source at the core

We want data structure and curation to be accessible to everyone, which is why foundational features of Data Studio are available in our open source edition, with Pro and Enterprise features to grow into as you need them.

Do I even need to care about Data Studio?

People tend to need some kind of data transformations when they have multiple sources of data (like your application and payments data), or a bunch of normalized tables. If you’re under 50 tables in your schema, don’t stress, watercress. If you have multiple data sources or a lot of tables, chances are you’ve been paying a tax on clarity, correctness, and performance. Data Studio can help get you sorted.

Data Studio is just one part of a bumper release. Check out what else is new in v59

How to get started with Data Studio

Data Studio ships with both OSS and EE editions (with some paid features).

Admins can find Data Studio from the top right grid icon. Some paid plans can grant non-admins access to Data Studio by adding people to the Data Analysts group.

Try Metabase Pro for free.

February 2026 vulnerability: What happened?

Mon, 02 Mar 2026 12:10:18 +0000

What happened?

Sho Odagiri, a security researcher, reported a vulnerability in Metabase’s notification API. The vulnerability allowed an authenticated user to craft a specially formatted notification template that could extract database connection details, including credentials, and send them via outbound email.

Who was affected?

We have no evidence that this vulnerability was exploited by any customer or malicious actor prior to the fix being released.

See the Fixed versions below, and find the latest point version for the Metabase version you’re running. If you’re running a point version below that version, you’re still vulnerable and should upgrade immediately.

Why did it happen?

Two independent changes introduced this vulnerability:

We updated the notification system to support user-supplied Handlebars templates for rendering email content.
We added metadata objects to query results, which could be traversed to access database connection details.

Together, these changes made it possible for an authenticated user to write a template that could extract sensitive database details via an outgoing email.

Part of what made this vulnerability difficult to catch is that the Handlebars library did not clearly document a method resolver that allows templates to invoke arbitrary Java methods.

What did we fix?

We addressed this vulnerability through two fixes:

Locked down the Handlebars template engine. We removed the method resolver from the Handlebars library configuration, which prevents templates from invoking arbitrary Java methods on objects in the rendering context. This eliminates the ability for user-supplied templates to traverse into internal objects.
Stripped metadata from query results used in notifications. We ensured that internal metadata objects—which previously could carry a reference to database connection details—are no longer present in the notification rendering context.

Fixed versions

All Metabase Cloud instances have been upgraded and are no longer vulnerable.

If you are self-hosted and haven’t already upgraded, please upgrade to one of the following versions (or higher) for your respective version.

Version 55: v0.55.20 / v1.55.20
Version 56: v0.56.20 / v1.56.20
Version 57: v0.57.13 / v1.57.13
Version 58: v0.58.7 / v1.58.7

What are we doing to prevent this in the future?

Along with the fixes we’ve made, we’re working through additional improvements to reduce risk:

Improving logging around template rendering so that we can audit user-supplied templates and detect unusual behavior.
Adding a wrapper around database credential access to prevent credential access outside of designated connection establishment paths.

Conclusion

Patches are live across all affected versions, and we have no evidence this vulnerability was exploited before the fix landed. We’re tightening template evaluation, locking down credential access paths, and improving logging to catch unusual behavior early.

If you’re self-hosted and haven’t upgraded already, please upgrade as soon as possible.

Credits

Hat tip to Sho Odagiri from GMO Cybersecurity by Ierae, Inc for discovering and disclosing this vulnerability.

Questions or concerns?

Reach out at support@metabase.com.

Security update available for Metabase - Please upgrade now

Thu, 19 Feb 2026 12:10:18 +0000

An independent security researcher Sho Odagiri from GMO Cybersecurity by Ierae submitted a severe issue with Metabase. We generally don’t blog about every bug, but this one is dangerous so we want to make sure that we reach out on all channels to our community to let them know that they should pay attention to this.

While we have no evidence that the vulnerability was ever exploited in the wild, and exploiting this vulnerability isn’t simple, if you are self-hosting Metabase, you should IMMEDIATELY update your Metabase instances (if you have not already).

The vulnerability

The vulnerability allows an authenticated user (including embedding users) to retrieve sensitive information from a Metabase instance, including database access credentials. For more info, check out the security advisory.

Are you affected?

Metabase Cloud customers don’t need to upgrade

No action needed. We’ve already upgraded your Metabase, and you’re no longer vulnerable.

All self-hosted Metabases, including customers, should upgrade immediately

IF you haven’t already, you should immediately upgrade to the latest point version of whichever Metabase version you’re running.

See the list of minimum safe releases below, and find the latest point version for the Metabase version you’re running. If you’re running a point version below that version, you’re still vulnerable and should upgrade immediately.

For example, if you are running 1.58.6, you should upgrade to 1.58.7 release or later. If you’re running a version of Metabase below version 55, you should upgrade to one of the versions listed below. You can find your current version by clicking on the “gear” icon in the upper right and selecting “About Metabase.”

If you’re running a custom fork of Metabase, reach out to us for the patches

Email us at help@metabase.com so we can provide you the appropriate patches.

Minimum safe releases for each Metabase version

The downloads below include the minimum safe release for each Metabase version.

55

v0.55.20

Docker image: metabase/metabase:v0.55.20
Download the JAR here: https://downloads.metabase.com/v0.55.20/metabase.jar

v1.55.20

Docker image: metabase/metabase-enterprise:v1.55.20
Download the JAR here: https://downloads.metabase.com/enterprise/v1.55.20/metabase.jar

56

v0.56.20

Docker image: metabase/metabase:v0.56.20
Download the JAR here: https://downloads.metabase.com/v0.56.20/metabase.jar

v1.56.20

Docker image: metabase/metabase-enterprise:v1.56.20
Download the JAR here: https://downloads.metabase.com/enterprise/v1.56.20/metabase.jar

57

v0.57.13

Docker image: metabase/metabase:v0.57.13
Download the JAR here: https://downloads.metabase.com/v0.57.13/metabase.jar

v1.57.13

Docker image: metabase/metabase-enterprise:v1.57.13
Download the JAR here: https://downloads.metabase.com/enterprise/v1.57.13/metabase.jar

58

v0.58.7

Docker image: metabase/metabase/v0.58.7
Download the JAR here: https://downloads.metabase.com/v0.58.7/metabase.jar

v1.58.7

Docker image: metabase/metabase-enterprise/v1.58.7
Download the JAR here: https://downloads.metabase.com/enterprise/v1.58.7/metabase.jar

Credits

We thank Sho Odagiri from GMO Cybersecurity by Ierae, Inc for discovering and disclosing this vulnerability.

Lessons learned from building AI analytics agents: build for chaos

Tue, 03 Feb 2026 00:00:00 +0000

Last year, I came back from a conference, pulled the latest code, and fired up our brand new version of Metabot to show our CEO the progress we’d made. While I was away, the team had been shipping new features and improvements.

My excitement quickly turned into one of the most embarrassing moments of my professional career. Metabot had transformed into a confused intern: eager to help but unable to remember what tools it had or how to use them.

But here’s the thing: this disaster taught us a lot about building production AI agents. In this post, I’ll walk you through what actually broke, why it happened, and the patterns we discovered that actually work in production for us.

If you want the full story with all the details, you can watch the talk we gave at the AI Engineering conference 2025 in Paris.

What we were building (and why it’s hard)

When we started building Metabot, the text-to-SQL space was already crowded: you describe what you want, give an LLM your database schema, and it generates SQL. Easy, right?

Yes and no.

The happy path works great - you’ve probably seen the demos with 5 well-documented tables and simple questions. But even if it works, there’s a problem: not everyone speaks SQL. A query can look fancy and return results, but how do you know if it’s answering the right question?

We wanted to go beyond SQL generation. Our goal was to leverage the Metabase query builder, a visual interface where users can click together queries and actually see what filters and aggregations are applied. This gives non-SQL users a way to validate and iterate on results themselves more easily.

But here’s where it gets hard:

SQL is baked into LLM training data. Our query builder language? Not so much.
Real customer data is messy: hundreds of tables, vague descriptions, legacy cruft.
Humans are notoriously bad at providing context: “How many customers did we lose?” (Which time period? What’s a “customer”? Logo churn or revenue churn?)

The real challenge wasn’t query generation. It was building an agent that could navigate this chaos by understanding what users are looking at, what they actually mean, and helping them find answers even when they don’t know how to ask the question.

That’s what Metabot set out to do. And that’s what spectacularly broke.

What broke: local optimization

The demo failure traced back to parallel development without integration testing. One engineer perfected the context awareness to make sure Metabot knew exactly what dashboard you were looking at. Another engineer optimized the querying tool, fine-tuning descriptions, parameters, and prompts until it worked beautifully in isolation.

Together, they created chaos.

The LLM doesn’t experience your architecture. It sees one context window: every instruction, every tool description, every piece of dynamic state, flattened into a single prompt. Our individually-optimized components were sending contradictory signals. Tool descriptions assumed different conventions. Instructions overlapped and conflicted. The model couldn’t figure out what we wanted because we were telling it multiple inconsistent things simultaneously.

The fix required thinking differently about what we were building. We weren’t building a querying tool with some context features. We were building a context engineering system. The LLM handles the generation; our job is to ensure it sees clean, unambiguous context at every decision point.

What worked: context engineering over prompt engineering

We stopped front-loading prompts and started engineering context throughout the agent’s lifecycle. Three patterns—optimized data representations, just-in-time instructions, and actionable error guidance—transformed how the LLM understood and used its tools

LLM-optimized data representations

We stopped dumping raw API responses into the context. Instead, we built explicit serialization templates for every data object Metabot works with — tables, fields, dashboards, questions — optimized for LLM consumption:

<table
  id=""
  name=""
  database_id=""
>
  ### Description  ### Fields | Field Name | Field ID |
  Type | Description | |------------|----------|------|-------------| 
</table>

This structured format gives the LLM consistent, hierarchical context it can parse reliably. Table metadata, field types, and relationships are always in the same place, reducing hallucination and tool misuse. The format is also reusable across all of Metabot’s tools, so when one person optimizes it, everyone benefits.

Use this pattern when your agent works with complex domain objects that appear across multiple tools or conversation turns.

Just-in-time instructions

Our original architecture front-loaded everything into the system prompt. The LLM ignored most of it.

So we tried something different: include instructions in tool results, right in the relevant moment:

{
  "data": "Chart created with ID 123",
  "instructions": """Chart created but not yet visible to the user.

  To show them:
  - Navigate: use navigate_to tool with chart_id 123
  - Reference: include [View chart](metabase://chart/123) in your response
  """
}

When a chart gets created, tell the LLM right then how to show it. The LLM pays attention to context that shows up exactly when it’s relevant, not buried in a system prompt from 20 messages ago.

Explicit error guidance

This pattern is more commonly known, but worth emphasizing: don’t just return error messages, return recovery paths instead.

{
  "error": "Table 'orders_v2' not found",
  "guidance": """This table may have been renamed or deprecated.

  Try:
  1. Search for tables matching 'orders'
  2. Check if 'orders' or 'order_items' fits your query
  3. Ask the user which orders table they want to use"""
}

The LLM handles ambiguity much better when you tell it how to handle ambiguity.

The benchmark problem in AI analytics agents

After the demo disaster, we built benchmarks. Scores climbed into the 90s, but perceived quality dropped.

The issue is subtle but important: engineers write benchmark prompts like engineers. “Count of orders grouped by created_at week.” Clean, precise, all context provided.

Real people say: “Why is revenue down?”

That question is missing a time period, revenue definition, comparison baseline, and probably some context about what triggered the question in the first place. And even if you nail the realistic test cases, there’s the uncontrollable data mess underneath - legacy tables, missing descriptions, inconsistent naming. The gap between benchmark coverage and production chaos is where AI products fail.

We now treat benchmarks as integration tests, not pure quality measures. If a change drops the score, something broke. But a passing score doesn’t mean the agent works, just that it handles clean inputs correctly. The real evaluation is production feedback, analyzed through a lens of what people actually asked versus what they needed.

Build for chaos, not happy paths

Our initial Metabot hackathon prototype had 5 perfectly documented tables and worked beautifully. Production has hundreds of tables with varying quality, used by people who phrase questions in wildly creative ways, and with edge cases we never imagined.

That’s the core lesson: don’t build for the happy path. Every polished demo with clean data creates expectations you can’t meet. People wander off the happy path in seconds. Better to understand the chaos, build for it, and deliver consistently than to show something impressive that falls apart on contact with reality.

We learned this the hard way. But it forced us to focus on what actually matters: robust context engineering, handling messy data gracefully, and building for the chaos that production inevitably brings.

Try it yourself

Metabot is now out of beta in Metabase. You can try it with your own data and see how these patterns work in practice. Pro tip: Do your homework and set up your semantic types like foreign key relations, metrics and segments. This will help improve the experience.

Want the full technical deep dive? Watch the complete talk from AI Engineer Paris 2025 where we go deeper into the implementation details.

These patterns apply beyond analytics agents. Any time you’re building with LLMs, think about the full context window, deliver instructions when they’re actionable, and always (always!) build for the chaos.

We simplified embedding

Tue, 13 Jan 2026 00:01:00 +0000

TL;DR: If you’re embedding Metabase and upgrading to 58, you don’t have to do anything. Your existing embeds will continue to work exactly as before. These changes are about simplifying our embedding options so it’s easier for people to pick the option they need.

What changed

Starting in Metabase 58, there are two ways to embed Metabase for new embeds.

Modular Embedding - Embed Metabase components, as Guest or as user via SSO.
Full-app Embedding - The full Metabase, SSO only.

If you’re already embedding Metabase, your existing embeds still work. Static embedding will still work for existing embeds, but new embeds must use Modular Embedding.

How the old options map to the new

Before 58	Starting in 58
Static embedding	Modular Embedding - Guest
Embedded analytics JS	Modular Embedding - SSO
Embedded analytics SDK	Modular Embedding SDK - Guest or SSO (React only)
Interactive embedding	Full-app Embedding - SSO only

Why we changed our embedding options

They were confusing. Static embedding was also somewhat interactive, but we also had interactive embedding, which was a different thing. Each had a different setup flow. It worked, but figuring out the right path could have been easier, so that’s what we did. Plus, the new Modular Embedding provides an easier upgrade path from static embedding—you can start with Guest embeds and upgrade to SSO without major code changes.

Modular Embedding overview

We built an in-app wizard that walks you through setup and generates a code snippet. Copy, paste, done. The choice you have to make is whether you give people in your app a Metabase account. If you do, it unlocks a lot of stuff, and reduces your maintenance burden.

Guest — People don’t need Metabase accounts. You sign embed URLs with JWT (just like static embedding), and they see the dashboard or question you’ve embedded. You can add and lock filters, but that’s about it. Guest embeds are available in the OSS Edition (with a “Powered by Metabase” badge) and on Pro/Enterprise.
SSO — People authenticate through your identity provider and get their own Metabase account. And since your Metabase knows who’s viewing what, it can unlock everything: drill-through, the query builder, AI chat, collection browser, and more, all with the correct permissions applied. Self-service embedded analytics.

Modular Embedding has an SDK for React, so if your app uses React, you should go with the SDK.

The nice part: Guest and SSO embeds share the same foundation, so it’s a much smoother upgrade path from Guest to SSO.

Upgrading existing embeds to 58

You don’t have to do anything special when upgrading. Your existing embeds will continue to work exactly as before.

Static embeds — Keep working. No code changes required. The iframe URLs, JWT signing, and parameter handling all work the same way. By default, you’ll see the new Modular Embedding wizard, but there’s an escape hatch: you can still access the legacy static embedding UI, configure embeds with the new wizard, and use the traditional iframe + JWT approach. Migrating to Modular Embedding SSO unlocks deep theming options that weren’t available with static embedding (Pro/Enterprise).
Interactive embeds — Keep working. Now called “Full-app Embedding,” but nothing changes on your end.
SDK embeds — Keep working. No changes to the SDK API. It’s just called the Modular Embedding SDK.

The only difference is what you’ll see in the Metabase UI when setting up new embeds.

Metabase | Business Intelligence, Dashboards, and Data Visualization

Winners of the Metabase AI Hackathon

Meta Chess, by Marat Surmashev

Claude’s Advice, by Owais Mumtaz

Improving the performance of the popular Clojure development tool clojure-lsp

Part 1: The mystery of heap headroom

Part 2: Profiling and optimizations

deep-merge

rewrite-clj improvements

Better memoization

Part 3: Measuring total allocations

Conclusions

How we built ten custom subagents to tame a 500K-line Clojure codebase

What are subagents and why did I make ten of them?

What’s inside an agent file?

The ten subagents

My Favorite: mbql-expert

How I actually use the agents

Tips for making your own subagents

More from Metabase Engineering

Metabase AI Hackathon

Join the hackathon

The AI tools to use

Prizes

Timeline

Meet Repro-Bot, our GitHub issue triage agent

Repro-Bot automates the boring parts

Results: repro steps, findings, possible root cause

How Repro-Bot works, and how to build your own

Integrating Repro-Bot into the workflow

What we learned

Meet Data Studio: tools to curate your semantic layer in Metabase

Analytics starts simple. Then it gets… less simple

Data Studio has all the tools you need to clean up the mess

The tools in the toolbox

Open source at the core

Do I even need to care about Data Studio?

How to get started with Data Studio

February 2026 vulnerability: What happened?

What happened?

Who was affected?

Why did it happen?

What did we fix?

Fixed versions

What are we doing to prevent this in the future?

Conclusion

Credits

Questions or concerns?

Security update available for Metabase - Please upgrade now

The vulnerability

Are you affected?

Metabase Cloud customers don’t need to upgrade

All self-hosted Metabases, including customers, should upgrade immediately

If you’re running a custom fork of Metabase, reach out to us for the patches

Minimum safe releases for each Metabase version

55

56

57

58

Credits

Lessons learned from building AI analytics agents: build for chaos

What we were building (and why it’s hard)

What broke: local optimization

What worked: context engineering over prompt engineering

LLM-optimized data representations

Just-in-time instructions

Explicit error guidance

The benchmark problem in AI analytics agents

Build for chaos, not happy paths

Try it yourself

We simplified embedding

What changed

How the old options map to the new

Why we changed our embedding options

Modular Embedding overview

Upgrading existing embeds to 58

Further reading