🗄️ Session Stores

Why a Store Matters

Recall the coat-check analogy from the last lesson: the browser holds a ticket (the session ID) and the real data hangs on a hook behind the counter. The session store is that counter. Everything about your app's reliability under load comes down to which counter you pick.

The good news: switching stores changes exactly one thing in your config — the store option. Every route you wrote in the last lesson keeps working untouched, because req.session is the same API no matter where the data is persisted.

The Cookie → Store Lookup

On every authenticated request, the middleware performs the same dance. Understanding it tells you exactly why store latency matters and where a TTL comes in.

Two things to notice. First, that GET happens on every request, so the store needs low latency — this is why Redis, an in-memory data store, is so popular. Second, the store enforces expiry itself via a TTL (time to live). When the TTL elapses, the store drops the session automatically, so stale sessions clean themselves up without a cron job.

The MemoryStore Trap

If you omit the store option, express-session uses a built-in MemoryStore. It's perfect for a five-minute demo and disqualifying for production.

The rest of this lesson is the fix: point store at Redis or MongoDB.

Redis with connect-redis

Redis is the most common choice: it's an in-memory key-value store built for exactly this — small values read and written constantly, with built-in expiry. Modern connect-redis (v6+) pairs with the redis v4 client.

Install & configure

npm install express-session connect-redis redis

// redis-session.js
require('dotenv').config();
const express = require('express');
const session = require('express-session');
const { RedisStore } = require('connect-redis'); // v6+ named export
const { createClient } = require('redis');

const app = express();

// 1) Create and connect the Redis client (v4 API returns promises).
const redisClient = createClient({ url: process.env.REDIS_URL }); // e.g. redis://localhost:6379
redisClient.on('error', (err) => console.error('Redis error:', err));
redisClient.connect().catch(console.error);

// 2) Build the store from the connected client.
const store = new RedisStore({
  client: redisClient,
  prefix: 'sess:',   // keys look like sess:abc123 — easy to spot & scope
  ttl: 60 * 60       // seconds the session lives in Redis (1 hour)
});

// 3) Hand the store to express-session — cookie flags stay exactly as before.
app.use(session({
  store,
  name: 'sid',
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 1000 * 60 * 60
  }
}));

app.get('/', (req, res) => {
  req.session.views = (req.session.views || 0) + 1;
  res.send(`Views: ${req.session.views}`);
});

app.listen(3000, () => console.log('Redis-backed sessions on :3000'));

redis-cli
KEYS sess:*            // list every session key (fine for dev; avoid on huge prod sets)
GET sess:abc123       // view one session's JSON
TTL sess:abc123       // seconds left before it expires
DEL sess:abc123       // force-logout a single session

MongoDB with connect-mongo

If your app already runs MongoDB, storing sessions there avoids adding another piece of infrastructure. connect-mongo (v4+) uses a factory method, MongoStore.create().

npm install express-session connect-mongo

// mongo-session.js
require('dotenv').config();
const express = require('express');
const session = require('express-session');
const MongoStore = require('connect-mongo');

const app = express();

app.use(session({
  store: MongoStore.create({
    mongoUrl: process.env.MONGODB_URI,   // mongodb://localhost:27017/app
    collectionName: 'sessions',          // where sessions are stored
    ttl: 14 * 24 * 60 * 60,              // 14 days, in seconds
    autoRemove: 'native',                // let Mongo's TTL index expire them
    touchAfter: 24 * 3600                // only re-write an unchanged session once/day
  }),
  name: 'sid',
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 14 * 24 * 60 * 60 * 1000     // 14 days, in milliseconds
  }
}));

const mongoose = require('mongoose');
MongoStore.create({
  clientPromise: mongoose.connection.asPromise().then(c => c.getClient()),
  collectionName: 'sessions'
});

SQL Stores

Already on PostgreSQL or MySQL and don't want to run Redis? There are battle-tested stores for SQL too. They're a touch slower than an in-memory store but keep your infrastructure count low.

// PostgreSQL example with connect-pg-simple
const session = require('express-session');
const pgSession = require('connect-pg-simple')(session);
const { Pool } = require('pg');

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

app.use(session({
  store: new pgSession({
    pool,
    tableName: 'session',
    createTableIfMissing: true,   // creates the table for you on first run
    pruneSessionInterval: 60 * 15 // sweep expired rows every 15 minutes
  }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: { httpOnly: true, secure: process.env.NODE_ENV === 'production', sameSite: 'lax' }
}));

Choosing a Store

There's no universal winner — match the store to your traffic and the infrastructure you already run.

Rule of thumb: reach for Redis by default in production — it's purpose-built for short-lived key-value data with expiry. Use Mongo or SQL when you already run one and want to avoid a new dependency. Use MemoryStore only on your laptop.

Practice & Quiz

const { RedisStore } = require('connect-redis');
const { createClient } = require('redis');

const redisClient = createClient({ url: process.env.REDIS_URL });
redisClient.connect().catch(console.error);

app.use(session({
  store: new RedisStore({ client: redisClient, prefix: 'sess:', ttl: 3600 }),
  name: 'sid',
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: { httpOnly: true, secure: process.env.NODE_ENV === 'production', sameSite: 'lax', maxAge: 3600000 }
}));

MongoStore.create({
  mongoUrl: process.env.MONGODB_URI,
  ttl: 14 * 24 * 60 * 60,
  autoRemove: 'native',     // Mongo TTL index removes expired sessions
  touchAfter: 24 * 3600     // skip re-writes unless a day has passed or data changed
});

Best Practices & Pitfalls

✅ Do

• Use Redis (or Mongo/SQL) in every non-local environment — never MemoryStore
• Set a sensible ttl and keep it aligned with the cookie maxAge
• Use touchAfter (Mongo) / keep disableTouch off thoughtfully (Redis) to control write load
• Namespace Redis keys with a prefix so sessions are easy to scope and flush
• Store the connection string in process.env, and enable TLS/auth on the store
• Keep session payloads tiny — ids and flags, not whole user documents

❌ Don't

• Ship MemoryStore and wonder why users get logged out after every deploy
• Open a second Mongo connection when you can reuse an existing client
• Expose Redis/Mongo to the public internet — put them on a private network
• Forget that ttl is in seconds while cookie maxAge is in milliseconds

Summary

📚 Additional Resources

• Express — compatible session stores
• connect-redis on GitHub
• connect-mongo on GitHub
• OWASP — Session Management Cheat Sheet

🚀 What's Next?

Your sessions are now fast, persistent, and shared. The last piece is hardening the one thing the client does hold — the cookie. Next: Cookie Security — httpOnly, secure, SameSite, cookie prefixes, and CSRF defense.