How Metabase impersonation with database roles puts database privileges in charge
If your analytics users should see only the data their role allows, and you already define that access inside the database, Metabase impersonation lets you keep the database as the source of truth. Impersonation maps Metabase user attributes to roles that you have defined in the database, so the database's own privileges decide what each person can see. Metabase does not need to duplicate those rules in its own permission model, and the same role boundaries apply whether a user writes SQL or builds a question with the query builder.
Impersonation is available only on the Pro and Enterprise plans. Metabase's pricing page lists Open Source and Starter as plans without it, and it lists row and column level permissions among the features included only in Pro and Enterprise. Confirm the current plan details on the pricing page before you budget, because the plan a team needs determines whether this approach is open to them at all. If your instance runs on Open Source or Starter, this topic is a decision about upgrading first, not about configuration.
The approach suits teams whose governance already lives in the database. If your data platform team already grants access through PostgreSQL, Snowflake, SQL Server or another supported engine, with roles, grants and policies maintained by people who own those systems, impersonation extends that model to Metabase instead of creating a second set of filters to maintain. It is a weaker fit when access rules are mostly defined in Metabase itself, or when analysts cannot be given stable database roles that match your business groups.
Before you commit, ask who will own the role definitions and how changes will be reviewed. A role change in the database takes effect for every Metabase question that runs under that role, so you should decide who can grant those roles, how new users get attributes mapped to them, and how an access review will show which role each Metabase user carries. Confirm with your database administrators which engines and versions your environment uses, since the supported list and the row-level security behavior differ by engine.
Which databases support Metabase impersonation with database roles
This table lists the seven databases that Metabase impersonation supports and the database-side control each one uses to filter rows for a role. Read each row as the place where your data team defines the access rule before Metabase sets the role for a query. Confirm the exact role and policy features of your database version with its vendor before you design the policies.
| Database | Database-side control to use | Planning note |
|---|---|---|
| ClickHouse | Row policies attached to roles | Define row policies per table and grant them to the roles Metabase will assume. Confirm how policies interact with your replication setup. |
| MySQL | Roles with grants on filtered views | MySQL has no native row-level security policy, so filters usually live in views that each role can read. Confirm role support for your version. |
| PostgreSQL | Roles with row-level security policies | Row-level security policies on views require PostgreSQL 15 or later. Confirm the role and policy features of your exact version with the vendor. |
| Redshift | Roles with row-level security policies | Attach row-level security policies to the tables or views each role reads. Confirm policy limits and grant syntax in current Redshift documentation. |
| Snowflake | Roles with row access policies | Attach row access policies to tables and grant access through roles that map to Metabase user attributes. Confirm policy and role behavior for your account edition. |
| SQL Server | Security policies with predicate functions | Use a security policy that filters rows through an inline predicate function, and grant the role access to the table. Confirm predicate and policy support for your SQL Server version. |
| Starburst/Trino | Row filters in the access control layer | Apply row filters through the access control rules of your Trino or Starburst catalog. Confirm which access control plugin your deployment uses and how it passes the role. |
How Metabase sets the database role before each query runs
Impersonation works in three steps. Metabase reads an attribute value from the signed-in user's profile, maps that value to a role that already exists in the target database, and sets that role on the database connection before the query executes. The database then evaluates the query under that role, applying its own table grants, column grants and row-level policies. Metabase never decides what a role can see. It only chooses which role the connection assumes. Your database administrators own the role definitions, and your Metabase administrators own the attribute values and the mapping from those values to role names.
The role is set before the query runs, so the same control applies to questions written in the SQL editor and to questions built in the query builder. A person who writes raw SQL cannot switch to a broader role by naming a different schema or table, because the connection is already operating as the mapped role. Confirm this behavior for each database you plan to use, since the supported list is limited to ClickHouse, MySQL, PostgreSQL, Redshift, Snowflake, SQL Server and Starburst/Trino. Test with a user who has a narrow attribute value and a query that names a table outside that role's grants. The query should fail or return only permitted rows.
Metabase does not replace database grants. If a role has broader privileges than intended, or if a row-level policy is missing, the database will return the data to anyone who can assume that role, regardless of how carefully Metabase is configured. Review each role for the minimum schema, table and column privileges it needs, and confirm that the connection account can switch to those roles but holds no more privilege than the most restricted role it can reach. For PostgreSQL row-level security on views, confirm that your server runs version 15 or later before you depend on that policy.
Plan for failure modes before go-live. A user attribute that is blank, misspelled or mapped to a deleted role may cause queries to fail, or in a poorly designed setup, fall back to a broader connection. Decide what the expected behavior is, then test it. Also decide who can change attribute values, because that person effectively controls data access. Record the mapping, the role definitions and the test results so an auditor or security reviewer can trace how a given user reached a given set of rows.
When to choose impersonation over Metabase row and column security
Impersonation with database roles fits teams whose access rules already live in their databases and who need one enforcement point. The criteria below help you choose between impersonation and row and column security, and both features sit on Pro and Enterprise plans.
Where access rules already live
Impersonation reuses the grants, roles and row-level policies your database already enforces, mapped from Metabase user attributes. If your authoritative access model sits in the database, the decision is largely settled. If it sits in a separate identity system or in Metabase groups maintained by hand, check whether those attributes can be mapped to database roles before you commit. Ask who maintains that mapping after go-live.
SQL and query builder coverage
Impersonation sets the database role before each query runs, so it applies to questions written in the SQL editor and in the query builder alike. Choose it when analysts write SQL against the same tables that business users explore visually. Confirm which of your SQL and query builder paths carry the role, then test each one under a restricted account before rollout.
One enforcement point outside Metabase
With impersonation, the database returns only the rows and columns the role allows, whichever application sends the query. That matters when other tools, pipelines or notebooks read the same tables. Check which of those clients connect with roles set by your organization, because a client using a shared service account can still read everything that account is granted.
Supported database engine
Impersonation is available for ClickHouse, MySQL, PostgreSQL, Redshift, Snowflake, SQL Server and Starburst/Trino. Confirm your engine and version against Metabase's current documentation before design work starts. For PostgreSQL row-level security policies on views, the database must run PostgreSQL 15 or later. If your engine is not on this list, plan on row and column security instead.
Row and column security as the alternative
Choose Metabase row and column security (formerly data sandboxing) when access rules live in Metabase attributes, when no database-side role model is planned, or when multi-tenant data is managed through Metabase. It uses attribute-based row filters or custom SQL views. Both features are included only on Pro and Enterprise plans, so plan tier does not separate the two options.
Planning the database role model for Metabase impersonation
The role model is the part of a Metabase impersonation project that decides most of the effort and most of the risk. Before anyone touches Metabase settings, the team should agree which database roles will exist, what each role is allowed to read, and how the people who use Metabase end up in those roles. Metabase impersonation sets a database role before a query runs, so the database's own grants and row-level policies become the access rules. If those roles are vague, the Metabase configuration will look correct and still expose the wrong data.
Start with an inventory. List the identity groups your organization already maintains, such as directory groups from your identity provider or LDAP, and the user attributes that describe who a person is and what they may see, such as region, business unit, or customer identifier. Then list the databases and schemas Metabase will query, and the tables, views and row-level policies that already exist in each one. Many organizations find that attributes they assumed were maintained are incomplete, stale or held in a system the analytics team cannot read. Record the owner of each source attribute, because that owner will be the one who fixes gaps later.
Next, define the database roles and their grants. Each role should correspond to a distinct data access decision, not to every individual person. For PostgreSQL 15 and later, decide whether row-level security policies will sit on tables or on views, since the platform's row-level security policies on views work only on PostgreSQL 15 and later. For Snowflake, SQL Server and the other supported databases, confirm with the database vendor's documentation how role inheritance, default roles and policy functions behave. Write each grant down as a short statement of purpose, and remove any role that cannot be explained in one sentence.
Then decide how user attributes map to roles, and who may change that mapping. A mapping table is easier to review than logic scattered across Metabase settings, so the team should agree the exact rule for each attribute value and what happens when an attribute is missing or has an unexpected value. The default for a missing value should deny access. Assign ownership explicitly: the database team typically owns roles, grants and policies, the analytics team owns the Metabase side of the mapping, and the security owner approves changes to either. Put this in a change process that names who requests, who reviews and who deploys.
Finally, review the complete role model with the security owner before any production mapping is created. Ask them to test the design against a short list of people and access cases, including one user with no attributes, one user with conflicting attributes and one user who should see nothing. Confirm the review result in writing, and treat later changes to roles or attributes as changes that repeat this review. Plan for this loop to take longer than the Metabase setup itself, because it is where the access decisions are made.
Setting up Metabase impersonation with database roles, step by step
This sequence takes a team from confirming the plan and database to testing impersonation as each mapped user. It ends with evidence that the database's own role privileges and row-level policies govern what each person sees in both SQL and query builder questions.
Confirm the Metabase plan is Pro or Enterprise
Check the edition on the Metabase admin settings for both the test and production instances. Impersonation access is available only on Pro and Enterprise, so an Open Source or Starter instance must move to one of those plans before any other work begins. Ask the person who manages the Metabase license to confirm the plan in writing and to record which edition each environment runs. This step is done when both environments show a Pro or Enterprise plan and the confirmation is on file.
Confirm the database type and version
Verify that your database is one of the types Metabase supports for impersonation: ClickHouse, MySQL, PostgreSQL, Redshift, Snowflake, SQL Server or Starburst/Trino. Then record the exact server version by running the database's own version query. For PostgreSQL, row-level security policies on views work only on PostgreSQL 15 and later, so a older server changes the design in step four. Confirm the supported version range with the vendor documentation for your database. This step is done when the type and version are written down and the row-level approach is chosen.
Create test roles and grants in a non-production database
Using a database administrator account, create one test role for each access level the business needs and grant only the schemas, tables and columns that role should read. Do this in a non-production database that holds representative or masked data, never in the production database. Connect as each test role outside Metabase and confirm it can read the tables it was granted. Then confirm that a query against a table it should not see fails with a permission error. This step is done when each allowed query succeeds and each denied query returns an error for the test role.
Define row-level policies where filtering is needed
Where a role should see only some rows, define row-level security policies on the underlying tables or on views. The policy should key off the database role or session context so that the filter follows the role Metabase sets. On PostgreSQL 15 or later, apply the policies to the views that Metabase queries, and confirm the view owner and grants match your design. Test by connecting as each test role and counting rows, then comparing the counts with the expected subset from the source data. This step is done when each test role returns only its own rows and the counts match the expected values.
Map user attributes to database roles in Metabase
In the Metabase admin settings, define the user attribute that holds the database role name and set it for each test user or group. Use the exact role names created in the database, because a case or spelling mismatch is a common cause of failed impersonation. Confirm the impersonation setting is enabled for each target database connection. Check the mapping by reviewing a sample user's attribute value against the role list in the database. This step is done when every test user resolves to the intended role and no user is left without an attribute.
Run test questions as each mapped user
Sign in as each mapped test user and run the same question in both the SQL editor and the query builder. Compare the returned columns and row counts with the results from running the same query directly in the database under the matching role. A denied table should produce an error in Metabase, and a row-filtered table should return only the permitted subset. Record each result against the expected outcome in a test log that the security or data owner can review. This step is done when all test users pass on both question types and the log is signed off by the data owner.
Security considerations for database roles and service accounts
Impersonation moves access control into the database, so the database accounts that Metabase uses become the main place where permissions are granted, inherited and audited. The cards below cover the accounts Metabase connects with, how their grants are scoped, and where credentials and logs live so you can review each one before rollout.
Connection account that switches roles
Metabase connects to the database with one account and then sets a role for each query based on the signed-in user's attributes. That account must be allowed to switch into each mapped role, but it should not hold privileges beyond what those roles need. Review whether it can also create objects, alter roles or read tables outside the mapped set, and confirm how your database restricts role switching for that account.
Least-privilege grants on base tables
Each database role should receive only the grants required for the analyses it serves, usually select on specific base tables or views rather than whole schemas. Row-level security policies and column grants then decide what each role sees. Check that no role has write access, that sensitive tables are excluded from default grants, and that new tables do not become readable by existing roles without a deliberate decision.
Inherited grants from broad roles
Database roles often inherit membership from other roles, and a role created for one team may pick up grants from a parent group added years earlier. Because Metabase applies the database's own privileges, an inherited grant can widen what a person sees without any change in Metabase. Map the full membership chain for every role used in impersonation and remove inheritance that the analysis does not need.
Protecting stored database credentials
Metabase keeps the connection details for each data source in its application database, and those details include the credentials of the account that switches roles. Anyone with read access to that application database, or to its backups, could obtain the connection account. Confirm where the application database lives, who can query it, how backups are encrypted and stored, and how credentials rotate after staff changes.
Audit trail in Metabase
Metabase records activity such as logins, questions run and administrative changes, which helps show who queried which data source. Usage analytics and auditing are listed as Pro and Enterprise features on Metabase's pricing page, so confirm that your plan provides them before relying on them for review. Decide how long these records are kept and whether they are exported to your central logging system.
Audit trail in the database
The database log is the only place that shows which role each query actually ran under, so it is the evidence to rely on when verifying impersonation. Confirm how your database engine logs role switches, whether statements executed after a role change are attributed to the mapped role, and whether connection-level logs capture the service account. Test this with a known user before production use.
Operating impersonation through upgrades and access changes
The ongoing work starts with access reviews. Impersonation only enforces what the database role allows, so when someone changes teams, the user attribute that maps them to a role must change too, and the old role must come off. A stale mapping keeps granting access the person no longer needs, and Metabase will not flag it. Set a recurring review that compares each user's Metabase attribute with the database role it resolves to, and trigger an extra review on every team transfer or offboarding. Confirm with your identity team how attribute values are sourced for your sign-in method, since the sync options for attributes depend on your plan and identity provider.
Database changes are the second trigger for review. Upgrading PostgreSQL, Snowflake, SQL Server or another supported engine, or editing grants and row-level security policies, can change what a role sees without any change inside Metabase. Treat each of these events as a reason to retest. If you rely on PostgreSQL row-level security policies on views, confirm first that you run PostgreSQL 15 or later, since that is the version this approach requires. Then build a short regression set: for each role, run one saved SQL question and one query builder question against a known table, and record the row counts and columns returned. Compare the results before and after the change. Because impersonation sets the role before both question types run, the same test covers the SQL editor and the query builder.
Metabase upgrades are the third trigger, and they touch the application database that stores your permission settings. Metabase runs application database migrations automatically when a new version starts. The upgrading documentation recommends backing up the application database before you begin. For major upgrades, reduce a clustered deployment to a single node because of a migration lock, and if your instance is on a version older than 40, upgrade one release at a time. Rollback is documented in two ways: restoring the pre-upgrade application database backup, which is the recommended path, or running the migrate down command with the newer JAR. Before the upgrade window, take the backup, test that it restores into a non-production environment, and write the restore steps into your runbook.
Version planning sets the rhythm for all of this. LTS versions are supported for 14 months, while non-LTS releases usually reach end of life after two months, and every release receives bug fixes and security updates until its end-of-life date. Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027, and Metabase 65 was released on 12 October 2026. Choose the release line that matches how often your team can run a full upgrade cycle, check the version support page before each planning cycle, and schedule role regression tests with every upgrade, including minor ones. Add the regression run to the upgrade's acceptance criteria so that a passing deployment is not treated as proof that impersonation still works.
What to confirm before you rely on impersonation
Impersonation moves access decisions into the database, so the checks below depend on your database engine and version, your identity provider, and your Metabase plan. Verify each item with Metabase and your database vendor before you commit to a design.
Database engine and version support
Impersonation is available for ClickHouse, MySQL, PostgreSQL, Redshift, Snowflake, SQL Server and Starburst/Trino. The engine list alone does not settle version questions, so confirm that your exact product and version are covered before you design roles around it. Ask Metabase for its current compatibility statement, then check your database vendor's documentation for how roles, grants and session settings behave in the version you run.
PostgreSQL version for view policies
Row-level security policies on views work only on PostgreSQL 15 and later. If you plan to filter rows through a view and your server runs an older release, impersonation alone will not enforce the restriction you expect. Check the server version, then test with a role that should see a subset of rows to confirm that the policy applies.
Identity provider attributes for role mapping
Impersonation maps user attributes to database roles, so the attribute your identity provider sends must exist and stay consistent for every person who queries data. Advanced attribute sync requires Pro or Enterprise. Confirm which attributes your provider can supply through JWT, OIDC or SAML, who maintains them, and what happens to a user whose attribute is missing or empty.
Metabase plan and included features
According to Metabase's pricing page, impersonation access is available only on the Pro and Enterprise plans, and the page lists Enterprise as priced by quote starting at $20,000 per year. Compare the plan against every feature your design needs, including SSO and attribute sync. Confirm current entitlements and prices with Metabase before budgeting, because plan contents can change.
SQL editor and query builder behavior
Metabase sets the database role before a query runs, so impersonation applies to questions written in the SQL editor and in the query builder. Test both paths for each role, including saved questions, dashboards and native queries that reference objects with different privileges. Record the results so reviewers can see that the same person receives the same rows from each question type.
Ownership of database roles and grants
The database roles that define each person's access must exist before Metabase can map to them, so your database team needs to create, review and document those roles and their grants. Confirm which team owns grant changes, how requests are approved, and whether your change process also covers the attribute-to-role mapping in Metabase. Unreviewed changes on either side can silently widen or narrow access.
Questions buyers ask about Metabase impersonation with database roles
Which Metabase plan do I need for impersonation with database roles?
Impersonation access requires the Pro or Enterprise plan. According to Metabase's pricing page, Pro is listed at $575 per month, or $517.50 per month billed yearly, with the first 10 users included and additional users at $12 per month. Enterprise is priced by quote, starting at $20,000 per year. The same page places row and column level permissions in Pro and Enterprise only, so Open Source and Starter cannot use this approach. Confirm current plan prices on the pricing page before budgeting, because list prices can change.
The plan decision is separate from the implementation work. Your database administrators still need to create and maintain the roles, and that work does not change with the plan.
How much does a Metabase impersonation project cost?
Cost depends on the scope written into the quote, not on a list price. The main components are the Metabase license tier you choose, the database and role design work, testing across your data sources, and identity mapping from your sign-in system to database roles. License cost recurs on Metabase's published schedule. Implementation is usually a one-time fixed-scope fee agreed in writing before work starts, and it may be followed by a retainer for upgrades and testing.
Ask for a quote that lists each database, the number of roles, the identity sources involved and the test cases covered, so you can compare it with an internal estimate on the same basis.
What drives the effort for database roles in Metabase?
The biggest drivers are how many roles you need, how many databases are involved, and how cleanly your identity provider groups or attributes map to those roles. A single PostgreSQL database with a few roles is a small job. Many databases across PostgreSQL, Snowflake, SQL Server or Trino, each with its own grants and policies, multiplies the design and test work.
Role design is the most important step. Roles that mirror real data ownership are easier to test and audit than roles built around individual users. Identity mapping adds work when attributes live in several systems or when group membership changes often.
Does impersonation work for questions in the SQL editor and the query builder?
Yes. Metabase sets the database role before the query runs, so impersonation applies to questions written in both the SQL editor and the query builder. This is why the database's own privileges, including row-level security, decide what each person sees.
Test both paths for each role. A role that looks correct in the query builder can still behave differently in a hand-written SQL question if views or grants were set up unevenly.
Which databases support Metabase impersonation, and what limits apply?
Metabase lists impersonation support for ClickHouse, MySQL, PostgreSQL, Redshift, Snowflake, SQL Server and Starburst/Trino. For PostgreSQL row-level security policies on views, the feature works only on PostgreSQL 15 and later, so check your server version before design starts. Confirm the exact configuration for your version and driver on the Metabase impersonation documentation page.
If one of your sources is not on the list, plan an alternative such as a governed view layer, and confirm that approach with the Metabase documentation before relying on it.
Can our internal team set up Metabase impersonation without a partner?
Often yes, if you have a database administrator who can design roles, a Metabase administrator on Pro or Enterprise, and someone who owns identity mapping. The work is mostly configuration and testing rather than custom code. Teams often handle the role design, grants and Metabase settings themselves, then bring in outside help for the parts they have less time or experience for.
The parts that usually benefit most from an outside review are cross-database testing, identity mapping across several providers, and documenting controls for an audit. DeployOpen plans, implements and tests this work in infrastructure you control, under a fixed scope agreed in writing.
What should we ask a partner for in a quote for this work?
Ask for a written scope that lists each Metabase instance, each database and its version, the role model with the number of roles, and the identity sources to be mapped. Also ask for the test plan, meaning which SQL and query builder cases will be checked for each role, and who runs them.
Ask which items are one-time and which recur, such as plan licensing, upgrades and retesting after schema changes. Also confirm what you will receive, including documentation and handover, and what you must provide, such as database access, test accounts and a named owner for decisions.
How DeployOpen scopes and delivers Metabase impersonation
DeployOpen plans and implements Metabase impersonation with database roles inside your own infrastructure, so the database's own privileges decide what each person sees. We agree the scope in writing first, then build, test and hand over the configuration with documentation your team can operate.
How we scope
- We inventory which target databases will use impersonation and confirm each one is on the supported list.
- We map your user attributes to the database roles that already exist or need to be created.
- We confirm your Metabase plan includes impersonation access, which requires Pro or Enterprise, before build work begins.
- Engagements are fixed-scope, so the written scope states which databases, roles and question types are covered.
How we build
- We configure role mappings in Metabase and set database connections to use impersonation for the agreed groups.
- We verify that row-level policies apply to questions written in both the SQL editor and the query builder.
- Where PostgreSQL row-level security runs on views, we confirm the server is version 15 or later before relying on it.
- We test each role with representative accounts and record which rows and columns each one can read.
How we hand over
- We document the role model, attribute mappings and the database grants that enforce them.
- We provide a verification checklist your team can rerun after schema changes or new database roles.
- We walk your administrators through troubleshooting denied queries and how to read the permission mappings.
- We agree how changes to roles and attributes are requested, reviewed and recorded before handover closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Metabase upgrades are planned with application database backups so impersonation settings can be reverified afterward.
- We can rerun the access tests when databases, schemas or Metabase versions change.
- Ask for the support scope, response arrangements and retest approach in the written quote.
