Logical views support two security modes that control how permissions are evaluated when accessing tables referenced by the view: DEFINER and INVOKER.
The security mode determines whose permissions are used when the view accesses underlying tables:
- DEFINER mode: The view executes with the permissions of the view owner
- INVOKER mode: The view executes with the permissions of the query executor
The default security mode is DEFINER, which follows the standard convention used by most database systems.
The security mode doesn't matter when a view references only tables that are stored in the same database as the view, because access control is performed at the database level. Security modes become relevant when views reference tables across different databases.
With DEFINER mode, queries against the view are executed using the permissions of the user who created (owns) the view, not the user executing the query.
Use DEFINER mode when you want to:
- Provide controlled access to sensitive data: Allow users to query specific columns or filtered rows without granting them direct access to the underlying tables
- Simplify permission management: Grant permissions once to the view owner instead of to every user who needs to query the view
- Create abstraction layers: Hide complex security logic behind a simple view interface
CREATE VIEW filtered_data.customers
SECURITY DEFINER
AS
SELECT customer_id, customer_name, country
FROM source_data.customers
WHERE country IN ('US', 'CA', 'MX');In this example:
- The view is created in the
filtered_datadatabase, while the referenced table is in thesource_datadatabase - The view owner has permission to access the
source_data.customerstable - Users who query
filtered_data.customersdo not need direct permission to thesource_datadatabase orsource_data.customerstable - All users see only customers from US, CA, or MX, regardless of their own permissions
- The view executes with the owner's permissions, which include access to the full
source_data.customerstable
Since access control is at the database level, to leverage DEFINER security mode effectively, the view should be defined in a different database from the database where the referenced tables are stored.
When views reference other views, each view's security mode is evaluated independently:
-- view_a references table_c
CREATE VIEW view_a
SECURITY DEFINER
AS SELECT * FROM table_c;
-- view_b references view_a
CREATE VIEW view_b
SECURITY DEFINER
AS SELECT * FROM view_a;When a query executes SELECT * FROM view_b:
view_bis accessed with the permissions of query executorview_ais accessed with the permissions of view_a's owner (DEFINER mode)table_cis accessed with the permissions of view_a's owner (DEFINER mode)
With INVOKER mode, queries against the view are executed using the permissions of the user who is running the query, not the view owner.
Use INVOKER mode when you want to:
- Enforce user-level permissions: Ensure each user sees only data they're authorized to access based on their own permissions
- Simplify query logic without changing security: Provide reusable query templates while maintaining existing permission models
- Audit who accessed what: Track access based on the actual query executor, not the view owner
CREATE VIEW analytics.all_customer_orders
SECURITY INVOKER
AS
SELECT o.order_id, o.customer_id, o.amount, c.customer_name
FROM source_data.orders o
JOIN source_data.customers c ON o.customer_id = c.customer_id;In this example:
- The view is created in the
analyticsdatabase, while the referenced tables are in thesource_datadatabase - Users must have permission to access both the
source_data.ordersandsource_data.customerstables - Each user sees only the data they're authorized to see based on their own permissions
- If a user lacks permission to the
source_data.customerstable, the query will fail
When views reference other views with INVOKER mode:
-- view_a references table_c
CREATE VIEW view_a
SECURITY INVOKER
AS SELECT * FROM table_c;
-- view_b references view_a
CREATE VIEW view_b
SECURITY INVOKER
AS SELECT * FROM view_a;When a query executes SELECT * FROM view_b:
view_bis accessed with the permissions of the query executor (INVOKER mode)view_ais accessed with the permissions of the query executor (INVOKER mode)table_cis accessed with the permissions of the query executor (INVOKER mode)
A logical view with DEFINER security mode should not reference a logical view with INVOKER security mode. This combination may lead to unexpected permission behavior and is not recommended.
| Aspect | DEFINER Mode | INVOKER Mode |
|---|---|---|
| Permissions Used | View owner's permissions | Query executor's permissions |
| Use Case | Controlled access to sensitive data | User-level permission enforcement |
| Permission Setup | Grant permissions to view owner only | Grant permissions to all users |
| Security Benefit | Restrict data access to specific columns/rows | Enforce existing permission model |
| Default | Yes | No |
When creating a view, specify the security mode in the CREATE VIEW statement:
-- DEFINER mode (default)
CREATE VIEW view_name
SECURITY DEFINER
AS
SELECT * FROM table_name;
-- INVOKER mode
CREATE VIEW view_name
SECURITY INVOKER
AS
SELECT * FROM table_name;If you don't specify a security mode, DEFINER is used by default.
You can change the security mode through the Data Workbench UI or using SQL.
Using the UI:
- Navigate to the view detail page in Data Workbench
- Select the menu (⋯) and choose Edit Details
- In the Edit Logical View Details dialog, select:
- Definer: Uses the permissions of the view creator
- Invoker: Uses the permissions of the current user
- Select Confirm to apply the change

Using SQL:
To change the security mode via SQL, use CREATE OR REPLACE VIEW:
-- Change to INVOKER mode
CREATE OR REPLACE VIEW view_name
SECURITY INVOKER
AS
SELECT * FROM table_name;When using CREATE OR REPLACE VIEW, you must re-specify the complete query definition.
- The view owner's permissions are critical when using DEFINER mode
- If the view owner is deleted, views with DEFINER mode will stop working
- Before deleting a user who owns DEFINER views, delegate ownership to another user with appropriate permissions
- Columns of logical views cannot be annotated with tags for data classification
- If a user has a column permission with colulmn permission (cannot view non-tagged columns), they cannot use logical views in queries
- This limitation applies regardless of security mode
- Logical Views - Complete guide to creating, viewing, and managing logical views