Best practice for switching Prisma databases based on request host?
Hey everyone!
I have a question about multi-tenant architecture using Prisma.
I need a single Node.js API to connect to different databases depending on the incoming request’s host.
Right now, my approach is to create multiple PrismaClient instances, one for each database, and then attach the correct instance to req based on the Host header.
Here’s a simplified example of what I’m doing:
const prisma_clinica_total = new PrismaClient({
datasources: { db: { url: process.env.DATABASE_CLINICATOTAL } },
});
const prisma_dental_arte = new PrismaClient({
datasources: { db: { url: process.env.DATABASE_DENTALARTE } },
});
const prisma_atend_ja = new PrismaClient({
datasources: { db: { url: process.env.DATABASE_ATENDJA } },
});
app.use((req, res, next) => {
const host = req.headers.host?.toLowerCase() || "";
if (host.includes("api.clinicatotal")) {
req.prisma = prisma_clinica_total;
} else if (host.includes("api.dentalarte")) {
req.prisma = prisma_dental_arte;
} else if (host.includes("api.atendja")) {
req.prisma = prisma_atend_ja;
} else {
return next(new Error("Unknown host: " + host));
}
next();
});
My question is:
Is this an acceptable / recommended practice with Prisma?
Or should I avoid multiple PrismaClient instances and instead run a separate API deployment for each database?
I’m looking for guidance on best practices for handling multi-database or multi-tenant setups with Prisma.
Thanks in advance!1 Reply
Skipping coffee for instant knowledge! Let's brew that AI answer now.
Yes, what you’re doing is a valid and currently recommended pattern for this kind of multi‑DB setup with Prisma.
Prisma doesn’t yet have first‑class multi‑tenancy support (migrations, management, etc.), so the main approach today is exactly what you described:
- Instantiate a
PrismaClient per database, overriding the datasource URL at construction time. [Client datasources; Multiple MySQL dbs]
- Route each request to the right client (e.g. based on host or tenant ID) and attach it to the request object. [Multi tenancy setup; Multi scheme / tenant]
For a small, known set of tenants (like your three URLs), your code pattern is fine and avoids per‑request client construction cost.
Things to keep in mind:
- Multiple clients are expected: Prisma team explicitly recommends keeping a map of Prisma Clients, one per database / tenant, and using the correct one per request. [Multi tenancy setup]
- Resource usage: Each PrismaClient instance has its own connection pool and some memory overhead; if the number of databases grows large or becomes dynamic, you’ll need lifecycle management (e.g. LRU cache, timeouts). [Multi tenant support; Performance in multi‑tenant]
- Alternative (many tenants): For high tenant counts, consider:
- a per‑tenant DB but with a client cache/factory that creates clients on demand and reuses them; [Isolating multi‑tenant data]
- or a single DB with per‑tenant schema when Prisma adds better support for that. [Multi‑tenant via schemas;
Multi tenancy setup]
Running separate API deployments per database is not required from Prisma’s point of view; your single‑API, multiple‑client approach is aligned with current guidance.
🤔 Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly.
In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.