# Choose a database for Deno

Deno can use mature database drivers through npm compatibility as well as Web and JSR modules. Choose from the data model, transaction needs, and hosting environment—not from which package looks most “Deno-native.”

| Data layer | Good for | Deno access |
| --- | --- | --- |
| PostgreSQL | relational data, transactions, complex queries | `npm:postgres`, `npm:pg`, Drizzle, Kysely |
| [SQLite](/en/docs/database/sqlite) | single-node, embedded, tests, small services | `node:sqlite` or compatible libraries; verify runtime version |
| MongoDB | document models and existing Mongo stacks | official npm driver or Mongoose |
| Redis | cache, rate limits, short-lived state | official npm client or compatible service |
| [Supabase](/en/docs/database/supabase) | managed Postgres plus Auth/Storage | official npm SDK or direct Postgres |
| [Deno KV](/en/docs/database/kv) | simple key-value and atomic operations | `Deno.openKv()`; verify hosting support first |

## Common connection boundary

```bash
deno run \
  --allow-env=DATABASE_URL \
  --allow-net=db.example.com:5432 \
  src/main.ts
```

- Reuse a pool over the module or application lifecycle; do not create one per request.
- Load secrets only from environment or a secret store, never source, logs, or error responses.
- Treat migrations as a release step; schema mutation during app startup multiplies concurrency risk.
- Serverless instances scale concurrently, so budget connections across the maximum instance count.
- Test connection failure, rollback, unique constraints, and timeouts.

The new Deno Deploy supports linked PostgreSQL, timeline isolation, and Deno KV, but data and migration policies still need to be designed per timeline. See [Deploy data and cron](/en/docs/deploy/data-and-cron).

Official references: [Connecting to databases](https://docs.deno.com/examples/connecting_to_databases_tutorial/) and [Deno database examples](https://docs.deno.com/examples/?category=databases).