Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#2,469 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
postgresql, typescript
Ambito
databases

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
2.9k
Fork
157
Merge medio
11h 42m
PR unite (30g)
20

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di zenstackhq/zenstack

Tutte le issue di zenstackhq/zenstack

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.