How to effectively use salt environments with pillars?

salt.conf

# GOAL: The different pillar root environments (base, dev, prod) will
# apply depending on which environment is being "run". The base pillar
# data would supply configs that apply to both environments. Each
# environment's specific pillar files would define overrides where
# necessary (e.g. enabling/disabling debug, settings based on dev vs prod
# VMs, etc).
#
# We don't have very many different states based on environment; in fact
# we want them all to be as close as possible. It's preferred that the pillar
# data be used to demarkate the differences between environments, but the
# VMs in prod vs dev would almost have the same `state`.
#

# QUESTIONS:
# * What does the salt call look like to target a given environment?
# * Is this setup overkill or not conventional/best practice?
# * In reality, we'll have different salt masters for each environment anyway
#   so this might be unnecessary?

# /etc/salt/master
# My understanding here is that order matters here. So a pillar file
# on the same relative path in /srv/pillar/dev/ would override base 
# for the dev environment.
pillar_roots:
  base:
    - /srv/pillar/base
  dev:
    - /srv/pillar/dev
    - /srv/pillar/base
  prod:
    - /srv/pillar/prod
    - /srv/pillar/base


# pillar/base/top.sls
base:
  '*':
    - groups
    - users
    - packages.common
    - hosts
    - sudoers
  # All DBs need this shared memory change
  '*db*':
    - sysctl.postgres
dev:
  # Development DB servers host all databases
  'dev-db*':
    - postgres.web
    - postgres.api
prod:
  # Production DBs are split up on different servers
  '*prod-web-db*':
    - postgres.web
  '*prod-api-db*':
    - postgres.api
    
# salt/top.sls
base:
  '*':
    - openssh
    - sudoers
    - sysctl
    - common.packages
    - common.groups
    - common.users
    - common.hosts
  # All DBs have the same state, but will receive different config
  # from the pillar top file above.
  '*db*':
    - postgres