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

Session Backend Cost Tradeoff

For a low-traffic Django project, the default database-backed session engine writes to the django_session table on every request that touches the session, which can dominate database costs even when overall traffic is modest. The signed_cookies backend moves session data into a signed cookie, eliminating that per-request database write.

However, that change introduces constraints: session data is signed but not encrypted, so clients can read the payload; server-side revocation is impossible before natural expiry; cookie size is practically limited to roughly 4 KB; and rotating SECRET_KEY invalidates all outstanding sessions at once. These behaviors are documented, but their practical impact depends on the installed Django version and how the application uses sessions.

Given these tradeoffs, what signals indicate that a low-traffic site should move from db or cached_db sessions to signed_cookies? Which session usage patterns make the loss of server-side invalidation unacceptable? How should the ~4 KB cookie ceiling and SECRET_KEY rotation policy factor into the decision?