Skip to main content
If you want PostgreSQL in a Next.js app on DBHost, the first decision is not the host. It is the data layer. The shortest useful split is:
  • Prisma if you want a full ORM and the fastest path to application models
  • Drizzle if you want SQL-shaped TypeScript with less abstraction
  • pg if you want a plain PostgreSQL client and no ORM at all
DBHost fits all three the same way: create a database, copy the pooled connection string, keep queries on the server, and let DBHost handle pooling, backups, and credentials.

​
Which path fits your app

PathBest whenWhat you getTradeoff
PrismaYou want the most guided ORM workflowSchema modeling, generated client, fast CRUD setupMore abstraction and generated code
DrizzleYou want typed SQL and lighter toolingSQL-first schema, typed queries, straightforward migrationsSlightly more hands-on than Prisma
pgYou want the thinnest possible layerDirect SQL, minimal dependencies, full controlYou own schema and query ergonomics yourself
For most small teams, Prisma is still the easiest first guide because it makes the end-to-end path obvious quickly. Drizzle should be the second guide, not an afterthought. It is the clearest alternative for teams that want stronger SQL ownership without dropping type safety. Plain pg should exist too because some teams do not want an ORM at all. That guide also becomes the clean reference for cron jobs, route handlers, and internal tools that just need SQL.

​
DBHost-specific fit

All three paths use the same DBHost building blocks:
  • one PostgreSQL database
  • one pooled connection string on port 6432
  • one place to manage passwords and backups
  • one dashboard, CLI, and API when the app later needs automation
That keeps the docs honest. The library changes. The platform path stays the same.

​
Guides

Prisma

Use Prisma when you want the fastest full-ORM path from schema to query.

Drizzle

Use Drizzle when you want a lighter SQL-first TypeScript workflow.

pg

Use node-postgres when you want direct SQL without an ORM layer.

​
What to add after these

If you keep expanding this section, the highest-value next docs are:
  • Kysely for teams that want a typed query builder without full ORM modeling
  • Node.js + pg outside Next.js for workers, scripts, and background jobs
  • postgres.js only if you start seeing real demand for that driver specifically
I would not spend early docs time on heavier legacy ORMs unless your users are already asking for them directly.

​
Next steps

  • Start with the guide that matches your current stack preferences.
  • Keep database queries in Server Components, route handlers, or server actions.
  • Use the same pooled DBHost URL across local development and deployment unless your migration workflow needs something different.