The difference between users, groups, and roles on Postgres, Redshift and Snowflake

Every so often, I fall down a rabbit hole – this time it happened to be on users, groups, and roles across Postgres, Redshift, and Snowflake.

I don’t know if anyone will find this useful, but I definitely found it interesting so thought it worth writing up what I found!

Postgres

We’ll start here, because Postgres generally sets the standard for relational databases.

In Postgres 9, users and groups were replaced with roles (Postgres have been very kind, and have maintained user and group as aliases for role for backwards compatibility). The difference between users and roles? Simply put, users can now be considered as roles with the ability to login.

  • Membership: Any role can be a member of another role, so you can create a hierarchical structure with as many tiers as you’d like.
  • Ownership: Any role can own relations.
  • Privileges: Any role can have privileges granted to it.
  • Inheritance: Up to you! Roles can be configured such that any members automatically inherit the privileges of the role, or can be configured to force a member to explicitly change their role in order to use those privileges.

Redshift

Redshift forked from Postgres somewhere around version 8. As such, roles look more like an old-school Postgres database rather than the role-based world of Postgres 9 – on Redshift, users and groups are separate entities.

  • Membership: Only a user can be a member of groups, i.e. a group cannot be a member of other groups, so you can only have a two-tiered structure.
  • Ownership: Users, rather than groups, own relations.
  • Privileges: Both users and groups can have privileges granted to them.
  • Inheritance: Users automatically inherit all privileges of any groups they are a member of.

Snowflake

Snowflake looks almost like the Postgres 9 view of the world, but abstracts users into a separate entity from roles. Users are just the login credentials, while roles look more like Postgres 9 roles.

  • Membership: Roles can be granted to users and to other roles, so you can create a hierarchical structure with as many tiers as you’d like.
  • Ownership: Roles, rather than users, own objects.
  • Privileges: Roles, rather than users, have privileges granted to them.
  • Inheritance: Users have to explicitly change their role in order to inherit the privileges granted to that role. Each user can have a default role.

Why does this matter?

This is good information to have if you’re used to working with one data warehouse and are switching to another (maybe you’re migrating warehouses, or maybe you’re changing jobs!). It also has implications for the best practices when setting up users and/or groups and/or roles in your warehouse – we’ve got a whole article on this coming out :soon:, stay tuned!

3 Likes