Database level permissions

Database roles provide the middle layer of Baserow’s permission hierarchy, offering more control than workspace-wide roles while being easier to manage than table-by-table assignments.

This guide covers how to assign roles at the database level to create department-specific access, protect sensitive databases, and override workspace-wide defaults for targeted permission control.

Paid feature: Role-based permissions are available on Baserow Advanced and Enterprise plans. View pricing details.

Overview

Database-level roles let you create permission boundaries around specific databases, giving members and teams different access to individual projects, departments, or client workspaces without changing their workspace-wide permissions.

When you assign a role at the database level, it applies to all tables within that database and overrides any workspace-wide role assignments. This creates natural permission boundaries; perfect for departmental databases (HR, Finance, Sales), client-specific projects, or sensitive data that requires restricted access.

Prerequisites: Members must first be invited to the workspace before you can assign database-level roles. You cannot invite members directly to a database.

When to use database-level roles

  • Use workspace-level roles when members need consistent access across all databases, you have a small, trusted team, or most databases have similar sensitivity levels
  • Use database-level roles when different groups need access to different databases, departments, or projects have distinct data boundaries, or some databases are more sensitive than others
  • Use table-level roles when need granular control within a database, individual tables require special restrictions, or specific sensitive tables (e.g., salary table in HR database)

How database roles work

Override behavior

Database-level roles override workspace-level roles but are overridden by table-level roles.

Learn more about role hierarchy.

Inherited vs. explicit access

The database members list shows only explicit assignments, not inherited access. Always check both workspace and database role assignments when troubleshooting access

A workspace Admin can access all databases, but won’t appear in individual database member lists unless you explicitly assign a database-level role. The database member list shows only exceptions to workspace defaults.

This matters because you might think a database has no members, but workspace-wide roles still grant access. To truly restrict a database, assign “No Access” to workspace members at the database level.

Assign roles at the database level

To grant database access to members or teams:

  1. Navigate to the database you want to manage

  2. Click the three-dot menu (⋮) next to the database name in the sidebar or home page

  3. Select Manage members from the dropdown

  4. In the Manage Members modal, click Select Members

    Manage database members option in Baserow

  5. Search and select members and/or teams using individual checkboxes, or the Select all button for bulk selection. The modal shows the total members selected

  6. Choose the role from the dropdown

  7. Click Invite members/teams

The role applies immediately to all tables in the database.

Assign roles to teams rather than individual members when multiple people need the same database access; it’s easier to manage as team membership changes.

View and modify database access

View current database members

The Manage Members modal displays all members and teams with explicit database-level role assignments.

This list only shows explicit database assignments. Members with workspace-level access may still access this database, but it won’t appear here unless they have a database-specific role assignment.

To see all effective access:

  1. Check workspace-level roles (Members page)
  2. Check database-level exceptions (Manage Members on database)
  3. Check table-level exceptions (Manage Members on tables)

Baserow Database members view image

Change existing roles

  1. Open the database’s Manage members modal
  2. Locate the member or team to modify
  3. Click the role dropdown next to their name
  4. Select the new role

Changes apply immediately to all tables in the database.

Remove database access

To revoke database-level access:

  1. Open Manage members on the database
  2. Select Remove from the role dropdown for that member/team

The workspace member loses database-level override and falls back to their assigned workspace-level role (if any). If the workspace-wide role is also restrictive, the member loses all database access

Removing database-level access cannot be undone directly; you must re-assign the role.

Database-level permission strategies

Strategy 1: Department databases with isolation

This strategy involves creating a separate, dedicated database for each department to establish clear data boundaries and manage access at a high level.

This approach is best for organizations that need to strictly separate sensitive information (like financial records or employee data) from more public, company-wide data.

You can configure this model in two common ways:

  • For sensitive databases (e.g., HR, Finance): Set the database-level permissions so that only members of the HR or Finance teams are invited. All other workspace members will have ‘No Access’ by default, fully isolating the sensitive data.
  • For general-access databases (e.g., Marketing, Public Directory): You can invite specific teams as ‘Editors’ while setting the default access for other workspace members to ‘Viewer’. This allows for company-wide transparency without risking accidental edits from other departments.

Strategy 2: Client project databases

This strategy is ideal for agencies, freelancers, or service providers who need to grant external clients read-only access to their specific project data. It ensures perfect isolation, as each client can only access the database they have been explicitly invited.

This approach is best for securely sharing project progress, deliverables, or reports with external stakeholders without letting them see other clients’ information or internal company data.

Implementation:

  1. Create a database per client: “Client A Project”, “Client B Project”
  2. Workspace level: Set all clients to No Role
  3. Database level:
    • Client A Project DB: Client A Team → Viewer or Commenter
    • Client B Project DB: Client B Team → Viewer or Commenter
    • Internal team: Editor on all client databases

This setup creates secure, isolated silos where clients can view their own project data, and your internal team retains full editorial control across all projects.

Strategy 3: Production vs. staging environments

This strategy involves duplicating your main database to create a distinct “staging” or “development” environment. This allows your team to test new integrations, experiment with field types, or build new application features without any risk of breaking your live, customer-facing “production” data.

This approach is best for development teams, citizen developers, or admins who need a safe sandbox to build and test workflows before deploying them to the main database.

Implementation:

  1. Create two databases: “Production” and “Staging”
  2. Workspace level: Developers → Editor
  3. Database level:
    • Production Database: Developers → Viewer, Admins → Admin
    • Staging Database: Developers → Editor (inherited from workspace)

Strategy 4: Graduated access model

This strategy mirrors a typical company’s organizational chart, providing hierarchical access. A “Leadership” or “Admin” team is given a “bird’s-eye view” with access to all data, while individual teams (like Marketing or Sales) are granted full access only to their specific departmental databases.

This approach is best for organizations that need to centralize high-level oversight for an executive team while keeping daily operations and data management siloed within their respective departments.

Implementation:

  1. Multiple department databases
  2. Workspace level: Leadership → Admin, teams → No Role
  3. Database level:
    • Each department DB: Department Team → Editor
    • Leadership team: inherits Admin from workspace

Troubleshooting database access

“Why can this member access the database when they’re not in the list?”

This is because they may have workspace-level access that isn’t overridden at the database level. Check their workspace roles. To restrict, assign “No Access” at the database level.

“I removed someone, but they can still access tables”

This is because they may have table-level role assignments that override database removal. Check individual table permissions and remove table-level access.

“Database Admin can’t invite workspace members”

Database Admins can only manage database access, not workspace membership. Only workspace Admins can invite members to the workspace. Have a workspace Admin invite a member first, then a database Admin can assign database access.

Frequently asked questions

Do database roles apply to new tables automatically?

Yes. When you create a new table in a database, all database-level roles automatically apply to that table unless you set table-specific overrides.

Can I assign database roles to members not in the workspace?

No. Members must first be invited to the workspace before you can assign database-level roles. Workspace membership is required.

What’s the difference between database “No Access” and removing the database assignment?

They’re effectively the same; both prevent database access. “No Access” explicitly blocks access, while removing the assignment removes the override (falling back to workspace role).

Can a database Admin restrict workspace Admin access?

Yes. A database Admin can assign “No Access” to workspace Admins at the database level, effectively creating a private database even if workspace Admins can’t access it (unless they override at the table level).

How do I make a truly private database?

Set “No Access” at the database level for all workspace members except the specific team that should have access. This overrides workspace-level permissions.

If I change someone’s workspace role, does it affect their database roles?

No. Explicit database-level roles always override workspace roles. Changing workspace role only affects databases where no database-level override exists.

Related content

Assign roles at other levels:

Understand the system:

Manage access:

Still need help? If you’re looking for something else, please feel free to make recommendations or ask us questions; we’re ready to assist you.