> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dbhost.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Next.js PostgreSQL Guide

> Choose Prisma, Drizzle, or node-postgres for connecting a Next.js app to DBHost with the right level of abstraction.

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

| Path    | Best when                              | What you get                                                | Tradeoff                                     |
| ------- | -------------------------------------- | ----------------------------------------------------------- | -------------------------------------------- |
| Prisma  | You want the most guided ORM workflow  | Schema modeling, generated client, fast CRUD setup          | More abstraction and generated code          |
| Drizzle | You want typed SQL and lighter tooling | SQL-first schema, typed queries, straightforward migrations | Slightly more hands-on than Prisma           |
| `pg`    | You want the thinnest possible layer   | Direct SQL, minimal dependencies, full control              | You own schema and query ergonomics yourself |

## Recommended default

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

<Columns cols={3}>
  <Card title="Prisma" icon="sparkles" href="/guides/nextjs-prisma">
    Use Prisma when you want the fastest full-ORM path from schema to query.
  </Card>

  <Card title="Drizzle" icon="cloud-rain" href="/guides/nextjs-drizzle">
    Use Drizzle when you want a lighter SQL-first TypeScript workflow.
  </Card>

  <Card title="pg" icon="database" href="/guides/nextjs-pg">
    Use node-postgres when you want direct SQL without an ORM layer.
  </Card>
</Columns>

## 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.