Metabase: self-service dashboards on a client's database, built in an afternoon

“Set up in five minutes”: that is the promise in Metabase’s README on GitHub, and installation really is quick. The real cost lies in what happens after those five minutes.

Metabase is built for exactly this job. The official repository describes it as an easy, open-source Business Intelligence and Embedded Analytics tool that lets everyone work with data.

So the real question is not whether you can build a dashboard in an afternoon. It is whether that dashboard stays safe once the client invites twenty more people to use it.

What does a typical afternoon look like?

Picture a distribution company. Order data sits in an operational database, and the regional managers want to see sales for their own regions. The first step is simple: Metabase publishes an official Docker image for the Open-source Edition. Pull it, run it, and you are done.

The second step is connecting the client’s database. The Metabase documentation asks you to give Metabase a database account with the right privileges, and points to a separate page on roles and privileges. Read that page before the meeting so you can ask the client to create a dedicated Metabase user in advance.

Before booking the session, check whether the client’s database is on the list of official drivers maintained by the Metabase team. Databases outside that list rely on community drivers. If that is your situation, test it beforehand rather than discovering problems in front of the client.

The third step is the one that wins the client over. Metabase calls each saved query a question. You build a few questions on sales by region and by month, collect them into a dashboard and let the regional managers click around. That is the afternoon gone. But this build is not yet production.

Why isn’t the demo production?

The default Docker setup stores Metabase’s own application data, meaning the questions, dashboards and user accounts you have just created, in embedded H2. The documentation is explicit: to run in production, you must store application data in a production-ready database.

So in the wrap-up email after the demo, list migrating the application database as a required task, not a footnote at the bottom.

Licensing is the second thing to spell out. The open-source edition is released under the AGPL, while the commercial editions come under a separate commercial licence. When you deploy for a client, especially one planning to embed dashboards in a product sold to others, their legal team needs to know this early.

Permissions go to groups, not individuals

The Metabase documentation states it plainly: permissions are granted to groups, not to individual people. When the client hires someone new, they simply add that person to the right group, and nobody has to reconfigure accounts one by one.

The “each regional manager sees only their region” problem is solved with row and column security: the rows and columns shown are restricted according to who is logged in. For the distribution company, a hypothetical permissions matrix might look like this.

Group	Tables visible	Columns to hide	Row restriction
Regional managers	Orders, Customers	Cost price, customer phone number	Only the logged-in user’s region
Finance	Orders, Invoices	Customer phone number	All
Warehouse operations	Orders, Inventory	Sale price, cost price	Only the assigned warehouse

Every cell in the table is a question the client has to confirm, for instance whether regional managers may see cost price. Draw up this matrix with the client before building a single chart. Do it the other way round and rework is almost guaranteed.

Embedding: where it is easiest to overpromise

Sooner or later the client will ask whether the dashboard can be embedded in their portal. Before you answer, know that static embedding has been deprecated and replaced by guest embeds.

A guest embed is protected by a JWT: Metabase loads the embed only when the request carries a JWT signed with a shared secret. But Metabase doesn’t know who is viewing, so per-user row and column security cannot apply. This approach suits shared figures that look the same to everyone.

If the portal serves multiple tenants and each tenant must see only its own data, the Metabase documentation recommends SSO-based embedding for multi-tenant self-service analytics. Steer the client in that direction from the start, rather than promising a guest embed and then finding that the permissions matrix above no longer does anything.

What are the two most common mistakes?

The first is connecting Metabase with the database admin account to save time. The demo runs smoothly, but every question users create afterwards runs through the account with the highest privileges on the client’s data.

The documentation asks only for an account with the right privileges. For view-only dashboards, a read-only user on exactly the schemas you need is a far safer choice.

The second mistake is letting the guest embed’s shared secret leak into frontend code. Because Metabase loads the embed for any request carrying a JWT signed with the correct secret, anyone who can read the secret can sign their own requests. The secret belongs on the client’s backend, and this point should go on the review checklist before handover.

What should you learn first?

Learn first whatever does the most damage when it breaks: database accounts and privileges, then the group permissions model with row and column security, then the embedding options. Dragging and dropping charts is something you can teach yourself in an hour.

On your CV, don’t just write “built Metabase dashboards”. Write that you designed group permissions for a given number of user groups, and why you chose a particular embedding type. An FDE recruiter reading that line will see that you understand the risks to a client’s data, not just how to use the tool.

Five minutes is enough to install Metabase, and an afternoon is enough for the client to like it. Whether the client trusts you depends on what you do about access that same afternoon.