When Should a Low-Traffic Django Site Switch to Signed-Cookie Sessions?

Direct Answer

Switch to signed_cookies only when three conditions hold: profiling shows session writes are a large share of database writes, the session payload is small and stable, and your application can tolerate no server-side logout before cookie expiry. If any condition fails, keep db or cached_db.

Likely Explanation vs. Confirmed Facts

The likely explanation for high cost is that the django_session table write volume dominates your database bill. The confirmed facts are the backend's documented constraints: signed cookies are readable by the client (signing prevents tampering, not disclosure), server-side revocation is impossible before natural expiry, the cookie must fit within roughly 4 KB, and rotating SECRET_KEY invalidates all outstanding sessions at once unless your Django version supports staged fallback keys.

Steps for This Case

1. Measure real session writes. Use CaptureQueriesContext or query logging around representative requests to count INSERT/UPDATE statements on django_session and inspect request.session.modified. With db or cached_db, Django saves only when the session is modified or SESSION_SAVE_EVERY_REQUEST is True; do not assume every request writes.
2. Compare against total database writes. If reads or table size dominate rather than writes, cached_db, a cache tier, or a read replica is safer than moving to signed cookies.
3. Measure the payload. Serialize a realistic session, add SESSION_COOKIE_NAME and attributes, and keep the signed value well under 4 KB. Verify with your actual browser and proxy stack because limits vary.
4. Audit invalidation flows. List every feature that requires immediate revocation: logout-all-devices, password-reset invalidation, bans, permission downgrades, step-up authentication, or concurrent-session limits. If any exist, signed_cookies is the wrong backend.
5. Check key rotation. If SECRET_KEY rotation is routine or compliance-driven, confirm your installed Django version supports fallback keys or keep server-side sessions.
6. Plan the migration. Changing SESSION_ENGINE effectively abandons existing sessions; expect forced re-login. After the change, test login, logout, CSRF, and any code that writes request.session.

One Missing Diagnostic

Do you require immediate session invalidation for security events? If yes, do not switch. If no and writes dominate, proceed only after the payload-size and rotation checks pass.

Version assumptions: the constraints above reflect Django's documented session framework. Exact serialization, compression, and SECRET_KEY fallback behavior vary by version, so inspect the installed backend before committing.