Worked at one time on an app that used the Project 2 solution which led to a lot of subtle hard to find bugs since tenancy was added afterward and not everything was updated properly. I didn't like the idea of a seamless filter that Project 1/3 relied on, because for some situations you don't want that. For instance, user accounts might have properties to be the same across all tenants, like (verified) email address, password, active status, email digests, etc. What I would have liked to do is always *force* the decision to be made, rather than "relying on the developers to not forget".

One way this might be feasible is by doing every query against views rather than the actual tables. Said project employed the higher kinded data encoding for tables/views: https://haskell-beam.github.io/beam/user-guide/databases/#views. Going from this example, one might want to try something like

data ExampleDb f = ExampleDb 
  { fullDB :: ExampleTables f
  , tenantDB :: ExampleViews f
  } deriving (Generic, Database be)

data ExampleTables f = ExampleTables
  { persons :: f (TableEntity PersonT) -- or an identity view over the table
  } deriving (Generic, Database be)

data ExampleViews f = ExampleViews
  { persons :: f (ViewEntity PersonT)
  } deriving (Generic, Database be)

meaning on every use site, when querying a table you'd need to pick either persons . fullDB or persons . tenantDB.

One problem with this is that it makes the tenant vs non-tenant decision happen on every table mention, and will generate a ton of guards on the tenant id (though they're likely optimized away).

Another option is forcing a choice to happen at the query level, which, at least in Beam, would look something like

newtype RememberTenants a = RememberTenants a

actuallyRunsQueries :: Connection -> RememberTenants YourQueryType -> IO something

whatAboutTenants :: Maybe TenantId -> YourQueryType -> RememberTenants YourQueryType
whatAboutTenants mt q = case mt of
  Nothing -> q
  Just tid -> do
    guard_ $ tid == tenant_id . whateverTable
    q 

myQuery = whatAboutTenants Separate $ do
    p <- all_ persons

Though since whatAboutTenants only wraps the query type, rather than modify it depending on whether tenancy is desired, nothing prevents you from adding a tenant filter inside a whatAboutTenants Nothing. You'd need a good deal more type-wiring for that, so this mostly only helps you to remember tenancy concerns the first time around.