Best BI tools for row-level security in 2026: 10 platforms compared

For a small company that needs strong row-level security (RLS), four options cover most cases. Power BI Pro ($14 per user per month) is the cheapest mature choice on Microsoft 365. Metabase Pro ($575 per month for 10 users) bundles row and column security, SAML SSO, and self-hosting on one published plan. Apache Superset is free and has built-in RLS filters if you can run it yourself. Basedash ($1,000 per month for up to 25 users) passes each user’s groups to PostgreSQL, so native database policies filter every AI-generated query. Looker, Tableau, Sigma, ThoughtSpot, Omni, and Lightdash all support RLS too. They differ on where the rule runs, how it reaches embedded dashboards, and which plan includes SSO.

This comparison is for teams where RLS is a hard requirement. That includes SaaS companies embedding customer-facing dashboards, sales and finance teams whose reps should see only their own accounts, and regulated organizations that must show an auditor where access control is enforced. Every price and plan detail below was re-checked against the vendor’s official pricing page or documentation on October 5, 2026.

TL;DR

• All 10 tools compared here can filter rows per user. They differ on enforcement layer, identity integration, embedded support, AI query coverage, and which plan includes the feature.
• Power BI is the cheapest mature RLS at $14 per user per month, but RLS only filters users with the Viewer role. Workspace Admins, Members, and Contributors see every row.
• Looker applies LookML access filters to every query path, including Conversational Analytics, but is quote-based and needs LookML developers.
• Sigma, Omni, ThoughtSpot, and Lightdash turn user attributes into SQL filters, which is the cleanest pattern for multi-tenant embedding.
• Metabase renamed data sandboxing to “row and column security” in version 0.56. It is on Pro and Enterprise only; the open-source edition and Starter have no row-level permissions.
• Apache Superset includes RLS filters in the free open-source project, and its embedded SDK can attach RLS clauses to each guest token.
• Basedash sets a basedash.groups session variable so PostgreSQL policies filter chat, dashboards, automations, and Slack answers. RLS is PostgreSQL-only, and embedded dashboards isolate tenants with locked filter values rather than database policies.

How we evaluated these tools

We built the criteria from the questions buyers actually ask AI assistants and Google about this topic, such as “best BI platform with strong row level security for a small company”, “which BI vendors include SSO and row level security in the base license”, and “which self-hosted BI dashboard tool supports PostgreSQL, row-level security, audit logs, and scheduled alerts for GDPR”. Each tool was checked on six points:

1. Enforcement layer and coverage. Does the rule live in the BI tool or the database, and does it filter dashboards, exports, schedules, embeds, and AI answers?
2. Identity. How user attributes or groups arrive (SAML, OIDC, JWT, SCIM), and on which plan SSO is available.
3. Embedded and multi-tenant support. Whether an embed session can carry per-customer attributes that the tool enforces.
4. AI query coverage. Whether the vendor documents that its natural-language or agent features respect RLS.
5. Plan gating and price. The lowest published plan that includes RLS, and the list price at small-company scale.
6. Deployment. Whether the tool can be self-hosted for data residency, GDPR, or air-gapped requirements.

Which BI tools have the strongest row-level security?

The table compares how each platform implements RLS. Prices are list prices verified October 5, 2026; quote-based vendors are marked as such.

What the comparison shows

Nine of the 10 tools define RLS inside the BI application. They differ mostly in how identity arrives (Entra ID, SAML attributes, JWT claims) and how the rule is written (DAX, LookML, YAML, saved SQL, a formula, or a GUI). Basedash is the outlier: it sets a session variable and lets PostgreSQL decide, which protects the same table from every tool that sets that context but only works on PostgreSQL. Metabase’s impersonation is a partial exception too, since it switches the database role per user on Pro and Enterprise.

The trade-off is configuration convenience versus enforcement scope. A Looker developer can add an access_filter quickly, and it protects every Looker query path. A PostgreSQL policy takes a database administrator and a migration, but it also holds when someone reaches the table through a SQL client or a second BI tool.

Which BI vendors include SSO and row-level security in the base plan?

Row-level security is rarely the gated feature. SAML SSO and SCIM usually are. This table shows the lowest published plan for each control, as of October 5, 2026.

Only Metabase Pro publishes a self-serve price that includes row-level permissions, SAML SSO, SCIM, and self-hosting together. Power BI gets close by handling SSO and provisioning in Entra ID rather than in the BI license, and Tableau includes SAML and SCIM from Standard. For the full plan-by-plan breakdown of SSO, SCIM, audit logs, and certifications across 11 tools, see BI tool security features by plan.

How does Power BI implement row-level security?

Power BI defines RLS as DAX roles in the semantic model. Static roles hardcode a filter (a “West” role that sees Region = "West"). Dynamic RLS uses a security table that maps user principal names to permitted values and a filter such as [UserEmail] = USERPRINCIPALNAME(), so one role serves thousands of users. Embedded reports pass the user and roles in an EffectiveIdentity on the embed token (Microsoft RLS docs).

The detail that trips teams up is scope. Microsoft’s documentation states that “RLS only restricts data access for users with Viewer permissions. It doesn’t apply to workspace Admin, Member, or Contributor roles.” Anyone you add to a workspace as a Contributor sees every row, so share reports through apps or Viewer access when RLS matters. Object-level security hides whole tables or columns, and it also applies only to Viewers.

Power BI fact card

• Best for: Microsoft 365 organizations with someone comfortable in DAX.
• Not ideal for: teams that grant workspace edit access widely, or teams on macOS, since Power BI Desktop runs only on Windows.
• Pricing (verified Oct 5, 2026): free account; Pro $14 per user per month and Premium Per User $24, paid yearly; 30-day Pro trial for up to 25 users (pricing).
• Deployment: Power BI service (cloud), or Power BI Report Server on-premises, which supports RLS (Report Server RLS).
• Query model: import (cached in memory) or DirectQuery (live).
• RLS, SSO, SCIM: DAX roles on Pro and above; users are Entra ID identities, so SAML federation and provisioning happen in Entra.
• AI: Copilot needs a paid Fabric capacity (F2 or higher) or Premium (P1 or higher), and “can only access data that the current user has permission to access” (Copilot requirements).
• Embedding: Power BI Embedded with embed tokens that carry the effective identity; priced by capacity.

How does Tableau handle row-level security?

Tableau offers several RLS options: manual user filters, dynamic filters built on USERNAME() or ISMEMBEROF(), entitlement tables joined to the data, and centralized data policies on virtual connections (Tableau RLS overview). Data policies are the strongest option because one policy covers every workbook that uses the connection, but they need Data Management, which is included in the Enterprise edition. For embedded analytics, connected-app JWTs can pass user attributes that USERATTRIBUTE() and USERATTRIBUTEINCLUDES() read once a site admin enables the setting (embedding docs).

Tableau documents that both of its AI surfaces respect RLS. Pulse metrics respect “row-level security applied to the data source”, and for Tableau Agent “user-defined policies for row and column level security are respected” (Tableau Agent docs).

Tableau fact card

• Best for: organizations that want centralized data policies and already standardize on Tableau or Salesforce.
• Not ideal for: small teams, because every Tableau Cloud plan needs an annual contract.
• Pricing (verified Oct 5, 2026): Standard edition Creator $75, Explorer $42, Viewer $15 per user per month; Enterprise edition $115, $70, $35; billed annually (pricing).
• Deployment: Tableau Cloud or self-managed Tableau Server.
• Query model: live connections or extracts. Extracts and subscriptions run with embedded credentials, so database-side per-user policies do not apply to them.
• RLS, SSO, SCIM: user filters on every edition, data policies with Data Management; SAML and OIDC; SCIM once SSO is configured.
• AI: Tableau Agent and Pulse, both documented to respect RLS.
• Embedding: Embedding API with connected apps and user attribute functions.

How does Looker handle row-level security?

Looker enforces RLS in LookML. access_filter maps a user attribute to a field and filters every query from an Explore, sql_always_where injects a WHERE clause, and access_grant restricts fields or Explores to users with certain attribute values (access_filter reference). Because the rules live in the model, they apply to dashboards, schedules, the API, and embedded content alike, and there is no user-facing override. User attributes can be populated from SAML attributes or OIDC claims.

Conversational Analytics, Looker’s Gemini-powered chat, “respects LookML row and column level permissions (for example, access_filters, access_grants, sql_always_where)”, according to Google’s Conversational Analytics API docs. Through the API, a shared key gives every caller the same access, so per-user enforcement needs per-user tokens.

Looker fact card

• Best for: Google Cloud teams that want every query to pass through a reviewed, version-controlled model.
• Not ideal for: teams without LookML developers, or buyers who need published pricing.
• Pricing (verified Oct 5, 2026): Standard, Enterprise, and Embed editions are quote-based with an annual commitment; each includes 10 Standard users and 2 Developer users, and Standard is capped at 50 users (pricing). Conversational Analytics has monthly data-token quotas with overage billing of $3 per million input tokens and $20 per million output tokens, currently paused under a promotion.
• Free trial: trial instances last 90 days (Looker docs).
• Deployment: Google-hosted.
• Query model: live in-database queries, plus persistent derived tables.
• RLS, SSO, SCIM: access filters and grants on all editions; SAML and OIDC; no native Looker SCIM endpoint documented.
• Embedding: signed and cookieless embedding on the Embed edition.

How do Sigma, ThoughtSpot, Omni, and Lightdash handle row-level security?

These four share one idea: user attributes resolve into SQL filters at query time. They differ in how the attribute is defined and how it reaches an embedded session.

Sigma

Sigma’s RLS adds a column to a data model table that calls CurrentUserAttributeText(), CurrentUserInTeam(), or CurrentUserEmail(), then filters on it (Sigma RLS docs). Sigma compiles the result to SQL that runs in the warehouse. In embedded content, the JWT’s user_attributes and team claims drive the same filters; Sigma notes that “JWT claims are specific to a user, not a session.” Sigma Assistant, the natural-language feature, “only works with data that you have access to” when RLS or column-level security is applied.

Sigma fact card

• Best for: Snowflake and Databricks teams whose analysts prefer a spreadsheet interface on live warehouse data.
• Not ideal for: buyers who need list prices, or teams that do not want to configure an AI provider.
• Pricing (verified Oct 5, 2026): quote only; 7-day free trial (trial docs).
• Deployment: cloud only.
• Databases: Snowflake, Databricks, BigQuery, Redshift, PostgreSQL, AlloyDB, MySQL, Starburst, SQL Server and Azure SQL, and ClickHouse (beta).
• Query model: live warehouse queries.
• RLS, SSO, SCIM: user attribute and team functions in data models; SAML; SCIM for users and teams.
• AI: Sigma Assistant and agents; an admin must first set up an AI provider, either a warehouse-hosted model or OpenAI, Azure OpenAI, Gemini, or Amazon Bedrock (AI setup).
• Embedding: JWT-signed embeds with user attributes and teams.

ThoughtSpot

ThoughtSpot uses rule-based RLS evaluated against the system variables ts_groups and ts_username (RLS concepts). Rules support direct column filters and access control list tables that map users to entitlements, which scales to thousands of groups. For Spotter, ThoughtSpot states that “all existing security rules, including column-level and row-level security, are strictly enforced” (Spotter data handling). In embedded deployments, pass entitlements through attribute-based access control (ABAC) in the trusted-auth JWT. Do not rely on runtime filters, which ThoughtSpot says are “not a security feature”.

ThoughtSpot fact card

• Best for: large organizations that want search-style analytics with RLS rules that scale through ACL tables.
• Not ideal for: small teams that want AI on the entry tier, since Essentials excludes Spotter.
• Pricing (verified Oct 5, 2026): Essentials from $25 per user per month for 5 to 50 users without Spotter; Pro from $50 per user per month with 25 Spotter queries per user per month; Enterprise custom; usage-based credits from $0.10 per credit; all billed annually (pricing).
• Free trial: 14 days, no credit card.
• Deployment: ThoughtSpot Cloud, or self-managed ThoughtSpot Software.
• Query model: live queries against the warehouse.
• RLS, SSO, SCIM: rule-based RLS; SAML and OIDC; SCIM on ThoughtSpot Cloud.
• Embedding: Visual Embed SDK with trusted authentication and ABAC via JWT.

Omni

Omni limits rows with access_filters on topics, which “limits access to rows in a dataset based on user attributes”, and controls topic and field access with access_grants (access filters). Because workbooks and AI queries resolve through the shared model, the filter applies to ad hoc exploration, dashboards, and embeds. Omni Agent generates Omni queries rather than raw SQL, so “the generated query respects the permissions set in Omni” (AI security).

Omni fact card

• Best for: data teams that want a governed semantic model with both workbook and SQL access.
• Not ideal for: teams that need self-hosting or published prices.
• Pricing (verified Oct 5, 2026): quote only; Omni publishes no pricing page; free trial on request.
• Deployment: Omni-hosted on AWS or Azure.
• Query model: live queries with caching.
• RLS, SSO, SCIM: access filters and grants on user attributes; SAML and OIDC; SCIM for Entra ID, Okta, and Rippling.
• AI: Omni Agent, running on a managed model by default (Claude on Amazon Bedrock, or Microsoft Foundry on Azure).
• Embedding: signed embed URLs with a userAttributes parameter.

Lightdash

Lightdash implements RLS with the sql_filter property on dbt models combined with user attributes, for example filtering a table by ${lightdash.attributes.tenant_id} (user attributes docs). Attributes can be set per user or per group and are part of the open-source edition. Embed JWTs accept an optional userAttributes object. Lightdash AI agents respect user attributes when they answer from the semantic layer; agent SQL mode, the SQL Runner, and the MCP “Run SQL” tool do not apply them (agent data access).

Lightdash fact card

• Best for: dbt teams that want RLS rules version-controlled next to their models.
• Not ideal for: teams without a dbt project, or small budgets on Cloud.
• Pricing (verified Oct 5, 2026): open source free to self-host; Cloud Pro $3,000 per month with unlimited users; Enterprise custom; 21-day trial without payment details; embedding and AI agents are priced add-ons (pricing).
• Deployment: Lightdash Cloud, self-hosted open source, or Enterprise on-premises.
• Query model: live queries compiled from dbt models.
• RLS, SSO, SCIM: sql_filter with user attributes on every edition; Google SSO on Cloud Pro; Okta, Azure AD, OIDC, and SCIM on Enterprise.
• Embedding: JWT embeds with user attributes.

How does Metabase handle row-level security?

Metabase’s RLS feature is called row and column security. Metabase’s docs say it “was formerly called data sandboxing” (docs), and the rename shipped in version 0.56. An admin either filters a table by a user attribute or assigns a saved SQL question (WHERE tenant_id = {{tenant_id}}) as the restricted view of a table for a group. Attributes arrive through JWT or SAML SSO and drive the same rules in modular and full-app embeds. Metabot, the AI assistant, “inherits the permissions of the person it’s chatting with” (AI settings).

Metabase also offers impersonation, which switches the database role per user so database-side policies apply. That works on ClickHouse, MySQL, PostgreSQL, Redshift, Snowflake, SQL Server, and Starburst. Impersonation and database routing are both Pro and Enterprise features. The free open-source edition and the Starter plan have no row-level permissions.

Metabase fact card

• Best for: small and midsize teams that want published pricing for RLS, SSO, SCIM, and self-hosting on one plan.
• Not ideal for: teams that need RLS on the free edition.
• Pricing (verified Oct 5, 2026): open source free; Starter $100 per month with 5 users, then $6 per user; Pro $575 per month with 10 users, then $12 per user; Enterprise from $20,000 per year; 14-day trial (pricing).
• Deployment: Metabase Cloud, or self-hosted on every plan.
• Databases: official drivers include PostgreSQL, MySQL, Snowflake, BigQuery, Redshift, Databricks, ClickHouse, SQL Server, Oracle, and MongoDB.
• Query model: live queries with optional caching.
• RLS, SSO, SCIM: row and column security, impersonation, and database routing on Pro and Enterprise; SAML and JWT SSO on Pro; SCIM on Pro and Enterprise.
• AI: Metabot on all plans with your own API key, or Metabase’s AI service on Cloud.
• Embedding: guest embeds (no user attributes), plus modular and full-app embedding with SSO attributes on Pro and Enterprise.

Does Apache Superset have row-level security?

Yes. Apache Superset includes RLS filters in the free, Apache 2.0 open-source project. An admin creates a filter with a SQL clause (department = 'finance'), assigns it to one or more datasets and roles, and Superset appends the clause to every query on those datasets; multiple filters combine with AND (Superset security docs). For multi-tenant embedding, the embedded SDK’s guest token request accepts an rls array, so your backend can attach a tenant clause to each viewer’s session (embedded SDK).

Preset, the managed Superset service, puts RLS behind role-based access control on its Professional and Enterprise plans. Two gaps matter for AI and power users. Preset documents that “RLS is not applied to SQL Editor”, and its AI Assist text-to-SQL feature runs in SQL Lab, so it is not RLS-filtered. The Preset Chatbot add-on does enforce RLS (Preset RLS docs).

Superset and Preset fact card

• Best for: teams that want free, self-hosted BI with RLS and are able to operate it.
• Not ideal for: teams that need native SAML without custom code, or AI features that respect RLS in SQL.
• Pricing (verified Oct 5, 2026): Superset free; Preset Starter free for up to 5 users; Professional $20 per user per month billed annually ($25 monthly) with a 14-day trial; Enterprise custom with SAML SSO, SCIM, and audit logs (Preset pricing).
• Deployment: self-hosted Superset, or Preset Cloud and Managed Private Cloud.
• Databases: more than 70 engines, including PostgreSQL, MySQL, Snowflake, BigQuery, Redshift, ClickHouse, SQL Server, and Databricks.
• Query model: live queries with a results cache.
• SSO: Superset authenticates through Flask AppBuilder (OAuth, OIDC, LDAP, database); SAML needs a custom security manager.
• Embedding: embedded SDK with guest tokens carrying RLS clauses.

How does Basedash implement row-level security?

Basedash takes a database-first approach. When a user runs a query against PostgreSQL, Basedash sets a session variable, basedash.groups, to the comma-separated list of groups that user belongs to (an empty string if none). You write ordinary PostgreSQL policies that reference that variable:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY orders_group_policy ON orders
  FOR SELECT
  USING (
    current_setting('basedash.groups', true) IS NULL
    OR department = ANY (
      string_to_array(current_setting('basedash.groups', true), ',')
    )
  );

The IS NULL branch keeps your application’s direct connections working unchanged, since only connections that set the variable (Basedash) are filtered. Because PostgreSQL applies the policy, it covers AI chat, saved charts and dashboards, scheduled automations (which run with the creator’s groups, and only the creator can edit them), and Slack answers (matched to the Basedash user; unmatched Slack users get an empty group list and no rows from group-restricted tables). Setup is in the row-level security docs.

Basedash fact card

• Best for: teams on PostgreSQL that want people to ask questions in plain English while the database enforces who sees which rows.
• Not ideal for: per-user RLS on Snowflake, BigQuery, MySQL, or other non-Postgres sources; SAML SSO at a self-serve price; or open-source self-hosting.
• Pricing (verified Oct 5, 2026): Startup $1,000 per month plus AI usage for up to 25 users, with $1,000 per month in AI credits; Enterprise custom; 14-day free trial with no credit card (pricing). RLS is not on the list of Enterprise-only features.
• Deployment: Basedash Cloud, or self-hosted on Enterprise with Docker Compose, Kubernetes and Helm, or an air-gapped install.
• Databases: native connections to PostgreSQL, MySQL, SQL Server, Oracle, Snowflake, BigQuery, Redshift, Databricks, ClickHouse, and others; MongoDB and other sources sync into Basedash Warehouse through Fivetran.
• Query model: live queries against the connected database.
• RLS: PostgreSQL policies keyed on basedash.groups. The RLS docs cover PostgreSQL only. Basedash Warehouse is a managed DuckDB warehouse with a Postgres-compatible endpoint, so confirm policy support with Basedash before relying on RLS there.
• Other access controls: data source access granted to everyone, a group, or a member, enforced in charts, chat, exports, and the SQL editor; organization-wide hiding of tables, schemas, and columns.
• SSO and SCIM: SAML 2.0 and OIDC (SSO docs) and SCIM provisioning on Enterprise.
• AI: AI data analyst chat, AI-generated dashboards, and an MCP server on every plan, which respects the same permissions.
• Embedding: Enterprise only. Dashboard embeds isolate tenants with secure filtering, where a signed JWT locks values such as tenant_id server-side. Full-app embeds sign users in with JWT SSO (embedding docs). The basedash.groups policy model is not documented for embedded viewers.
• Audit logs: Enterprise.

Basedash limitations

• RLS is supported for PostgreSQL only. Snowflake, BigQuery, MySQL, and other sources rely on those databases’ own access controls plus Basedash’s data source and table permissions. For Snowflake specifically, Basedash connects with one service role, so per-viewer Snowflake row access policies do not apply.
• Policies are group-based. Per-user isolation means one group per user or tenant, or a mapping table.
• Writing and testing CREATE POLICY statements needs someone comfortable with PostgreSQL.

For the database side, see how to enable row-level security in PostgreSQL. The full set of controls is on the security page.

Which BI tool has the best row-level security for a small company?

For a small company, three questions decide it. Can someone on the team write DAX, LookML, YAML, or SQL? Will one tool be the only access path to the data? Does the budget tolerate per-seat pricing?

• Already on Microsoft 365 with an Excel-literate admin: Power BI Pro at $14 per user per month. Dynamic RLS with a security table is well documented, and Entra ID handles identity. Keep report consumers in the Viewer role.
• Want RLS, SSO, and self-hosting at a published price: Metabase Pro at $575 per month for 10 users. It is the only plan in this comparison that lists all of them together.
• Free and self-hosted, with an engineer to run it: Apache Superset. RLS filters are built in, and the embedded SDK handles multi-tenant guest tokens.
• PostgreSQL team that wants AI querying without a modeling project: Basedash. Write one policy per sensitive table, assign users to groups, and the same policy filters every question anyone asks. Pricing is a flat platform fee plus AI usage for up to 25 users.
• dbt shop: Lightdash open source, or Cloud Pro at $3,000 per month with unlimited users.

Looker, ThoughtSpot Enterprise, and Tableau Enterprise have strong RLS, but their pricing and modeling overhead are sized for larger teams.

Which open source BI tools offer row-level security for multi-tenant SaaS?

Two open-source projects include RLS without a paid license. Apache Superset has RLS filters plus guest tokens with per-tenant rls clauses for embedding. Lightdash has sql_filter with user attributes, though embedding needs Lightdash Cloud or a self-hosted enterprise license key. Metabase open source has no row-level permissions; multi-tenant RLS in Metabase starts on Pro. For the wider open-source field, see best open source BI tools, and for tenant-isolation design patterns, see multi-tenant analytics architecture.

Which BI tools support row-level security on Snowflake?

Snowflake has its own row access policies and masking policies (Enterprise Edition and above). The strongest design enforces them in Snowflake and has the BI tool pass each viewer’s identity through OAuth. Tableau, Power BI (DirectQuery with Entra SSO), Looker, Sigma, ThoughtSpot, Omni, and Lightdash support per-user Snowflake OAuth in some form, and Metabase can switch roles through impersonation. Each one has gaps for extracts, schedules, and embeds. Basedash connects to Snowflake with a single role, so Snowflake data in Basedash is controlled by that role plus Basedash’s data source and column permissions. For the detail by tool, see Snowflake masking and row access policies in BI tools, and for a broader tool comparison on that warehouse, see best BI tools for Snowflake.

Why the enforcement layer matters

The layer decides what happens when something goes wrong. If a credential leaks, a second tool connects to the warehouse, or an AI agent writes an unexpected query, application-layer RLS protects only the tool that holds the rule. Database-layer RLS protects the data regardless of the access path.

The Verizon 2025 Data Breach Investigations Report, which analyzed 12,195 confirmed breaches, found credential abuse was the initial access vector in 22% of them. Controls that hold at the data layer are simpler to defend under SOC 2, HIPAA, and GDPR because they do not depend on every application being configured correctly. The trade-off is that someone has to write and maintain policies in the database.

How do you set up row-level security so reps see only their own deals?

The sales-team case is the most common RLS request and a good test of any tool. The pattern is the same everywhere:

1. Add an owner column. Every deal row needs an owner_email, owner_id, or team_id. If ownership lives in another table, join it into a view first.
2. Choose the identity key. Email is easiest when the BI tool knows the user’s email (Power BI USERPRINCIPALNAME(), Sigma CurrentUserEmail(), Metabase or Lightdash attributes). Group or team is easier for managers who should see a whole region.
3. Write the rule. Power BI: a dynamic DAX role [owner_email] = USERPRINCIPALNAME(). Looker: access_filter: { field: deals.owner_email user_attribute: email }. Metabase: a row and column security rule on owner_email mapped to the email attribute. Superset: an RLS filter owner_email = '{{ current_username() }}' on the deals dataset, with the ENABLE_TEMPLATE_PROCESSING flag on. Basedash: assign reps to groups and add a PostgreSQL policy that checks team = ANY(string_to_array(current_setting('basedash.groups', true), ',')).
4. Handle managers. Managers need a superset. Use a mapping table (manager to reps) joined in the rule, or a “sales-managers” group whose policy branch returns the whole region.
5. Test as a rep. Log in as a real rep account, check dashboards, exports, and an AI question like “show me all open deals,” and confirm the row count matches what the rep should see. In Power BI, test with a Viewer account, since Contributors bypass RLS.

What questions should you ask a vendor about row-level security?

• Where is the rule enforced, in your application or in my database, and what happens to a query that bypasses your application?
• Does RLS apply to exports, scheduled emails, API calls, embedded sessions, the SQL editor, and AI-generated queries? Show me each one.
• Which roles or admin types bypass RLS? (Power BI workspace Contributors and Metabase admins are common surprises.)
• How do user attributes arrive: SAML assertion, OIDC claim, JWT, SCIM, or manual mapping?
• Can one rule serve thousands of users (dynamic RLS), or do I create a role per group?
• Which plan includes RLS, SSO, SCIM, and audit logs, and what is the price at 25 and 100 users?
• How do I test RLS as another user before going live?

Which should you choose?

• Small company on Microsoft 365: Power BI Pro.
• Small company that needs SSO and RLS on a published plan: Metabase Pro.
• Self-hosted for GDPR or data residency: Metabase (any plan, RLS on Pro), Apache Superset, Lightdash open source, or Basedash Enterprise if you are on PostgreSQL and want AI chat.
• SaaS embedding with per-customer isolation: Sigma, Omni, or ThoughtSpot for attribute-driven embeds; Superset or Lightdash if you want open source. For a wider list, see the embedded analytics platform comparison.
• Governance-heavy enterprise with a modeling team: Looker or Tableau Enterprise with data policies.
• Teams that don’t write SQL and want AI answers that cannot leak rows: Basedash on PostgreSQL, where the database filters every AI query, or ThoughtSpot Pro, where Spotter enforces RLS rules.

Frequently asked questions

Which self-hosted BI dashboard tool supports PostgreSQL, row-level security, audit logs, and scheduled alerts for GDPR?

Metabase is the most complete published option. It can be self-hosted on every plan, connects to PostgreSQL, and has alerts and dashboard subscriptions. Pro and Enterprise add row and column security, database impersonation, and usage analytics and auditing. Apache Superset is free to self-host with built-in RLS filters and alerts and reports; check whether its built-in action log meets your audit requirements. Basedash Enterprise self-hosts with Docker or Kubernetes, enforces PostgreSQL policies on every query including automations, and includes audit logs. Self-hosting helps with GDPR data residency, but you still need a lawful basis and retention rules.

Which BI vendors include SSO and row-level security in the base license?

Few do on their entry plan. Power BI is the closest: every Pro user signs in through Microsoft Entra ID, and DAX roles are included. Looker includes SAML and access filters on all editions, but all editions are quote-based. Tableau Cloud includes SAML and user filters on Standard, though centralized data policies need Enterprise. Metabase includes both on Pro, its second paid tier. Lightdash, Preset, and Basedash include RLS below Enterprise but keep SAML SSO for Enterprise, while Sigma, Omni, and ThoughtSpot do not publish which tier includes SSO. Ask for plan gating in writing before you sign.

What are the best practices for setting up row-level security and access controls in a self-service analytics tool?

Use one dynamic rule driven by a user attribute or group instead of a role per region. Source those attributes from your identity provider through SAML or SCIM so they stay in sync. Index the filtered column. Restrict who can edit models or join tables, because a new join can widen access. Check that exports, schedules, embeds, the SQL editor, and AI chat all honor the rule. Test as real restricted users, including one with no groups. Finally, review which roles bypass RLS, such as Power BI workspace Contributors, and keep those groups small.

How do AI-powered BI platforms handle row-level security without slowing down dashboard load times?

They push the filter into the SQL the warehouse runs, so the cost is one extra predicate. Keep the filtered column indexed in PostgreSQL or MySQL, or clustered in Snowflake and BigQuery. Avoid policies that call a function or subquery per row. Per-user filters reduce cache sharing: Sigma disables its shared cache under OAuth, and Omni keeps per-user caches. To keep caching effective, filter on group or tenant rather than individual email where you can. In Power BI, import mode evaluates DAX roles in memory, which is usually faster than DirectQuery.

How do leading AI BI vendors handle row-level security for cross-functional teams?

Most map each department to a group or attribute and let the AI generate queries through the same governed path as dashboards. Looker’s Conversational Analytics respects access filters and grants. ThoughtSpot Spotter enforces RLS and column-level security. Sigma Assistant, Omni Agent, and Metabase’s Metabot all inherit the user’s permissions. Basedash sets the user’s groups in a PostgreSQL session variable, so finance and sales can share one AI chat while the database returns different rows to each. Watch for exceptions: Lightdash agent SQL mode and Preset AI Assist in SQL Lab skip RLS.

Which embedded BI tools let us apply row-level security per customer and still query Snowflake live?

Sigma, Omni, ThoughtSpot, Looker, and Lightdash all query Snowflake live and accept per-customer attributes in the embed token: Sigma through JWT user attributes, Omni through userAttributes in the signed URL, ThoughtSpot through ABAC claims in a trusted-auth JWT, Looker through embed user attributes, and Lightdash through userAttributes in the embed JWT. Superset’s guest tokens carry rls clauses and also query Snowflake live. Power BI Embedded with app-owns-data can apply DAX roles, but it cannot pass Snowflake SSO identities. Basedash embeds lock a tenant filter value in a signed JWT rather than using Snowflake policies.

Does Basedash support row-level security?

Yes, for PostgreSQL databases, on the Startup plan and above. Basedash sets a basedash.groups session variable on every PostgreSQL query with the user’s groups, and your policies reference it. AI chat, dashboards, automations (run with the creator’s groups), and Slack answers are all filtered by PostgreSQL rather than by the app. Other databases use their own access controls plus Basedash’s data source permissions and column hiding. Embedded dashboards on Enterprise isolate customers with secure filtering, where a signed JWT locks a filter such as tenant_id server-side.

Can users bypass row-level security?

Not inside a correctly configured tool, but every tool has roles that RLS does not filter. In Power BI, workspace Admins, Members, and Contributors see all rows. Metabase admins are never impersonated. Database owners and anyone holding warehouse credentials can query directly unless the policy is forced on the owner. The larger risk sits outside the BI tool: a SQL client, a second BI tool, or a leaked credential. Database-layer policies close that gap. Also confirm the SQL editor is covered, since Preset documents that RLS does not apply there.