The 4-Role Security Model for Your Data Warehouse

Read The Starter Guide for Modern Data (Free): https://www.kahandatasolutions.com/startermds Most teams hand out database permissions user by user. It works until it doesn't. In this video I walk through the alternative: roles as containers for permissions, users assigned to roles, and a four-role baseline that maps directly onto a complete data architecture layout. We start with the basics of how users, roles, and database objects actually connect, then layer a security model on top of the end-to-end pipeline: landing zone, transformation layers, dev environments, and production. The four baseline roles: 1. Loader. Full ownership of the raw/landing layer. Assigned to dedicated users for ingestion tools like Fivetran, Stitch, or a custom Python job. No visibility into anything downstream. 2. Analyst. Read-only access to the marts layer. Business stakeholders and analysts get what they need to analyze, and nothing else. This prevents rogue tables and conflicting metrics. 3. Developer. Read access to raw data, full ownership of the dev environment, read-only on production. Enough to build, not enough to break production by accident. 4. Automation. Read access to raw, ownership of production and CI schemas. This is the role behind your scheduled refreshes and deployment jobs, not a human user. The theme running through all of it: start with the least amount of permission necessary and add on only when there's a reason. The small amount of friction that creates is a feature. It routes requests back through your workflow instead of around it. Chapters 00:00 Why database security matters 00:30 Users, roles, and objects at a high level 01:12 Why roles beat direct user permissions 01:30 Walking through a multi-role example 03:44 The 4-role baseline overview 04:32 Role 1: Loader 05:51 Role 2: Analyst 07:40 Role 3: Developer 09:00 Role 4: Automation 09:57 Putting the full picture together