Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Feature Request] Switch between postgres schemas for multi-tenant use-cases

Open
  • Is something wrong?
#2,469 0 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
postgresql, typescript
Domain
databases

Research direction

Read the Kysely schemas recipe linked in the issue and then trace how ZenStack builds its Kysely query-builder calls and its Prisma client wrapper, since a schema switch has to affect both. The thread is an open design discussion with no agreed API, so the first step is a written proposal covering how the schema/search path is set per request and how a single query can override it for cross-schema joins. Done means a reviewable design plus the touched entry points, not a patch.

Written by the indexing model from the issue text.

Description

Is your feature request related to a problem? Please describe.
For multi-tenant applications, where there is one tenant per postgres schema, a common requirement is switching the schema based on the tenant. See kysley docs here

Describe the solution you'd like
An api to switch schemas so that in both the query builder api and also the prisma api the sql ends up qualified with the proper schema name/search path. For cross-schema queries, overriding this should work too as mentioned in kysely docs. This means that the db client instance and thereby the connection pool would be shared across all schemas, which is efficient.

A strategy might be that when switching to a schema, it affects prisma query api calls and the kysely query builder calls, but only in kysely can the schema be changed within a single query to do cross schema joins. To enable this in prisma api, an optional schema argument would need to be added somehow.

Describe alternatives you've considered
Create one postgres client per tenant and cache them in memory, disposing them when they go out of use. Each request gets a client along with its db connection pool depending on the tenant id. For low amount of tenants this is ok, but high usage will have a large number of open conn pools which may not be ideal.

I am open to thoughts, ideas on this topic and how best to support it here and in general.

Dominant language
TypeScript
Stars
2.9k
Forks
157
Avg merge
11h 42m
Merged PRs (30d)
20

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from zenstackhq/zenstack

All issues in zenstackhq/zenstack

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.