Preview feature feedback: @prisma/adapter-pg / PostgreSQL Driver support
#22899
Replies: 12 comments 11 replies
-
|
Hey @nikolasburk! The feature looks great but it seems that Prisma prepends all select statements with the SELECT "public".* FROM "TABLE"Is there a way to get prisma to not include the schema in the resulting query — that way the user can configure the default schema on the pool? Alternatively, is there a way to inform Prisma of the schema? |
Beta Was this translation helpful? Give feedback.
-
|
Hi |
Beta Was this translation helpful? Give feedback.
-
|
I just wanted to highlight that this feature is incredibly useful for us because it makes using Prisma with passwordless DB authentication possible despite it not currently being supported out of the box. For example using IAM passwordless login via CloudSQL proxy for Google Cloud SQL using Cloud Run or Cloud Functions: import { PrismaPg } from "@prisma/adapter-pg";
import { PrismaClient } from "@prisma/client";
import { GoogleAuth } from "google-auth-library";
import { Pool } from "pg";
const auth = new GoogleAuth({
scopes: ["https://www.googleapis.com/auth/sqlservice.login"],
});
const pool = new Pool({
host: "/cloudsql/REDACTED",
user: "REDACTED",
password: async (): Promise<string> => {
return (await auth.getAccessToken()) as string;
},
database: "postgres",
ssl: false,
idleTimeoutMillis: 0,
max: 5,
});
const adapter = new PrismaPg(pool);
export const prismaClient = new PrismaClient({
adapter,
});I hope it reaches general availability soon 🤞 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for adding the pg driver adapter team! Would love to see driver adapters reach GA. We switched to the driver adapter in prod recently and its been working very well. Idle connections are actually closed properly compared to the native driver, since the native driver connection pool of mobc does not close idle conns after a timeout like most other pools (ex: https://github.com/brettwooldridge/HikariCP?tab=readme-ov-file#frequently-used and https://node-postgres.com/apis/pool#new-pool). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feature! Based on the implementation, it looks like @prisma/extension-read-replicas won't work in combination with this postgres driver. Are there any plans for supporting this in the future (maybe on the adapter itself)? Edit: Looks like read replicas are currently broken even with the native DB driver. |
Beta Was this translation helpful? Give feedback.
-
|
I am trying to use this adapter with a Vike + Hono site deployed to Cloudflare Pages but receive the following error when trying to read from the database: Any pointers? |
Beta Was this translation helpful? Give feedback.
-
|
If before creating the Prisma Client I add my own type parser like so: This should make Prisma convert Dates using this mapping function. |
Beta Was this translation helpful? Give feedback.
-
|
This is my
/**
* Prisma Client initialization with Singleton pattern.
* This module exports a single Prisma Client instance named 'db' for use across your application.
*
* Usage:
* ```typescript
* import db from 'path_to_this_file';
*
* Example usage
* const users = await db.user.findMany();
* ```
*/
import { Prisma, PrismaClient } from '@prisma/client'
import { Pool } from 'pg'
import { PrismaPg } from '@prisma/adapter-pg'
//import { PrismaPg } from '@prisma/adapter-pg-worker'
// Extend the global object to include 'prisma' property
declare global {
// eslint-disable-next-line no-var
var prisma: PrismaClient | undefined
}
// Initialize the PostgreSQL connection pool
// const pool = new Pool({ connectionString: process.env.DATABASE_URL })
// Initialize the PrismaPg adapter with the connection pool, The PrismaPg adapter is the component that connects Prisma to the PostgreSQL database using the specified configuration for connection management.
const adapter: PrismaPg = new PrismaPg(
{ connectionString: process.env.DATABASE_URL },
{
// Optional: specify schema if needed
// schema: 'myPostgresSchema',
}
)
// Extend PrismaClient to accept the custom adapter
interface CustomPrismaClientOptions extends Omit<Prisma.PrismaClientOptions, 'datasources'> {
adapter: PrismaPg
}
class CustomPrismaClient extends PrismaClient {
constructor(options: CustomPrismaClientOptions) {
super(options as Prisma.PrismaClientOptions) // Cast to base type
}
}
// Access the global object and extend it with 'prisma' if necessary
const globalForPrisma = global as typeof global & { prisma?: PrismaClient }
// Create a singleton instance of PrismaClient
export const db =
globalForPrisma.prisma ||
new CustomPrismaClient({
adapter,
log: [
{
emit: 'event',
level: 'query'
},
'info',
'warn',
'error'
]
})
// Attach an event listener for query events (optional)
db.$on('query' as never, async (e: Prisma.QueryEvent) => {
// Define a list of tables to exclude from logging
const excludedTables = ['"lms"."User"', '"lms"."Account"'];
// Check if the query is for any of the excluded tables
if (excludedTables.some(table => e.query.includes(`FROM ${table}`))) {
return; // Skip logging for excluded tables
}
// Log the query if it does not match the excluded tables
console.log('Query: ' + e.query);
console.log('Params: ' + e.params);
console.log('Duration: ' + e.duration + 'ms');
});
// In development mode, store the instance globally to prevent multiple instances
if (process.env.NODE_ENV !== 'production') {
globalForPrisma.prisma = db
}
// Export the PrismaClient instance as the default export
// export default db |
Beta Was this translation helpful? Give feedback.
-
|
I am facing the problem that enum arrays are not parsed correctly when using I am receiving |
Beta Was this translation helpful? Give feedback.
-
|
Hello, any suggestions for the fix of this issue? |
Beta Was this translation helpful? Give feedback.
-
|
I recently switched to pg adapter + prisma 6.16 and noticed that since then, the tables and types in migrations are prefixed with the schema name. In our E2E tests, we pop a test container and use one schema per test suite. Because the schema name is present in the migrations, the DB setup fails (prisma complains that identifiers prefixed with The temporary solution is to clean manually the migrations before merging PRs, but this is time consuming and error-prone (already pushed 3 bad migrations while working on a new feature). Is there any way to restore the previous behaviour which omitted the schema name in migrations? |
Beta Was this translation helpful? Give feedback.
-
|
Recently switched to the adapter -- any reason we're hard-coding |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Support for the
node-postgresdriver (pg) is in preview behind thedriverAdapterspreview feature.Please share your feedback about
@prisma/adapter-pgin this discussion.Beta Was this translation helpful? Give feedback.
All reactions