Dbt Secure View
You create a dbt secure view by setting the secure option in your model settings. This setting tells your cloud warehouse to hide the view logic and stop optimizer bypasses. Data teams use this feature to share filtered tables with outside users or other groups. Still, broad database roles still let users run full queries against exposed columns. How a dbt secure view works in your warehouse Standard database views do not always keep underlying rows hidden from curious users. In a normal view
VNC Secure Access + Database View-Based Access Control: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You create a dbt secure view by setting the secure option in your model settings. This setting tells your cloud warehouse to hide the view logic and stop optimizer bypasses. Data teams use this feature to share filtered tables with outside users or other groups. Still, broad database roles still let users run full queries against exposed columns.
How a dbt secure view works in your warehouse
Standard database views do not always keep underlying rows hidden from curious users. In a normal view, the query engine merges user filters with the view logic. That optimizer trick makes queries run fast across big tables. Yet a user can write a tricky filter that forces an error on hidden rows. That error can leak facts about rows the user should not read.
Setting up a dbt secure view changes how the warehouse runs the query. During a build, the tool adds a special keyword to the view creation statement. You can turn this setting on inside a single model file. You can also set it for a whole folder in your main project file. Once built, the warehouse runs the internal view logic before any user filters run.
The warehouse also hides the SQL text that defines the view from normal roles. Only the view owner and top admin roles can read the underlying SQL logic. Other users only see the final column names and the rows they can read.
What native view settings solve and what they miss
This native feature solves two specific problems inside a cloud data warehouse. First, it stops users from reading the SQL text that builds the dataset. Second, it stops query optimizers from running user functions before row filters take effect. This setup works well when you share data across business units or partner accounts.
Still, a secure view has real limits in daily team workflows. Because the optimizer cannot push user filters down early, queries often run much slower. The database must scan and filter the whole base table before applying user limits. Teams must test query speed on large tables before turning this setting on everywhere.
VNC Secure Access + Database View-Based Access Control: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
More importantly, view settings only control the shape of a stored database object. They do not inspect live queries or check who is sitting at the keyboard. If an analyst logs in with a broad role, the view returns every permitted column. If that view includes emails, phone numbers, or card numbers, those values arrive in full. Native view rules decide who logs in, not what individual statements do in flight. Teams also need dynamic masking to rewrite matched fields like national IDs in results.
When to use secure views in your data models
You should not turn on this setting for every model in your project. Internal staging tables do not need hidden SQL logic or strict optimizer limits. Using it everywhere wastes compute credits and makes daily dashboard refreshes drag on.
Save this setting for final reporting models that enforce strict row-level filtering rules. If a table filters rows based on the current user role, mark it secure. If a model hides sensitive business formulas from external readers, mark it secure as well. For all other tables, standard views and table builds give much better query speed. Pair those standard builds with runtime controls that check queries and rewrite sensitive fields.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Does a dbt secure view slow down warehouse queries?
Yes, it can slow down queries on large tables. The warehouse must run the view filters before it applies any user query filters. This rule stops the query planner from skipping unneeded table partitions early.
Which data warehouses support the secure view setting?
Several major cloud data warehouses support this feature through standard model settings. Support depends on the specific database adapter your project uses during a run. Check your adapter docs to confirm if your warehouse engine honors this flag.
Does a secure view mask sensitive columns automatically?
No, a secure view only hides the view SQL and enforces row filter order. If a column contains emails or phone numbers, permitted users still get those values. You must add separate column masking rules to rewrite sensitive fields in query results.