---
title: "PgBouncer en mode transaction : Prisma, Django, Rails"
url: https://while.sh/fr/guides/pgbouncer-postgresql/
author: "Aloïs Oddon, cofondateur de Nextmap"
updated: 2026-11-02
---

# PostgreSQL derrière PgBouncer : Prisma, Django, Rails et vos migrations, avec votre agent IA

Votre base PostgreSQL sur while passe par PgBouncer, pour tenir des centaines de clients à la fois. Votre agent IA sait ce que ça change pour votre code, et le règle pour vous.

## Prérequis

- Une appli en ligne sur while, avec sa base PostgreSQL.
- Votre agent IA, branché à while par MCP.

## Étape 1 : Demandez une vérification

> Vous, à votre agent : Vérifie que notre code marche derrière PgBouncer.

Votre agent relit votre code et vos réglages de base, et corrige ce qui suppose de garder la même connexion à la base d'une requête à l'autre.

## Étape 2 : Ce qui a besoin d'une session passe à part

Ce qui a besoin d'une session entière, comme `pg_restore` ou une migration qui fait des `SET`, tourne dans une tâche, que votre agent lance aussi à la demande. Elle reçoit l'adresse directe de la base dans `DB_MAIN_DIRECT_URL`.

## Ce que fait votre agent

En mode transaction, chaque transaction peut prendre une autre connexion. Les requêtes préparées sont suivies : Prisma et node-postgres marchent sans réglage. Un `SET` de session, un verrou consultatif ou un curseur côté serveur, eux, ne passent pas d'une transaction à l'autre (source 1). Pour régler la session, votre agent utilise `SET LOCAL`, dans une transaction :

```js titre="server.js"
const client = await db.connect();
try {
  await client.query('BEGIN');
  await client.query("SET LOCAL statement_timeout = '5s'");
  await client.query('SELECT count(*) FROM commandes');
  await client.query('COMMIT');
} catch (e) {
  await client.query('ROLLBACK');
  throw e;
} finally {
  client.release();
}
```

## Régler Django

> Vous, à votre agent : Règle Django pour PgBouncer.

Votre agent coupe les curseurs côté serveur :

```python titre="settings.py"
DATABASES["default"]["DISABLE_SERVER_SIDE_CURSORS"] = True
```

## Régler Rails

> Vous, à votre agent : Règle Rails pour PgBouncer.

Votre agent coupe les verrous consultatifs des migrations :

```yaml titre="config/database.yml"
production:
  primary:
    url: <%= ENV["DATABASE_URL"] %>
    advisory_locks: false
```

## Garder Prisma tel quel

> Vous, à votre agent : Utilise Prisma pour les migrations.

Votre agent laisse Prisma sur `DATABASE_URL`, migrations comprises : rien à changer. Il ne déclare pas de `directUrl`, que Prisma réclamerait au démarrage avec l'erreur P1012 : l'adresse directe n'est donnée qu'aux tâches.

## Trouver les requêtes lentes

> Vous, à votre agent : Quelles requêtes ralentissent la base ?

Votre agent lit les requêtes les plus fréquentes et les plus lentes de votre base, relevées par pg_stat_statements.

## Prochaines étapes

- [Mettre en ligne une API Node.js et sa base PostgreSQL](/fr/guides/api-node-postgresql/)
- [Mettre en ligne une appli Django](/fr/guides/appli-django/)
- [Remettre votre base à un instant précis](/fr/guides/restaurer-une-base/)

## Sources

1. [PgBouncer, ce que permet chaque mode de regroupement](https://www.pgbouncer.org/features.html), 2026-11-02

## Questions

### Faut-il ?pgbouncer=true pour Prisma ?

Non : PgBouncer suit les requêtes préparées, et l'adresse de DATABASE_URL marche telle quelle.

### Puis-je me connecter sans PgBouncer ?

Une tâche, oui : elle reçoit l'adresse directe dans DB_MAIN_DIRECT_URL. Votre appli passe toujours par PgBouncer.

### Combien de clients en même temps ?

Selon la taille de la base : 200 en S, la taille par défaut, 400 en M, 600 en L, 800 en XL.