Hi, author here. That's a fair question! The database code I presented there isn't just to database-ify sessions, but to provide user->sessions association, which none of the existing stores do. That technique is applicable to AR stores as well as others, and essentially provides users with control over their list of purportedly active sessions. The first solution I presented was just a simple server-enforced timeout on sessions which doesn't require any DB work.

I think it's still worthwhile to use CookieStore even if you're going to go to the DB, because:

1. You only do DB round-trips for cookies that contain a valid user ID, and you're going to be pulling that user record anyway, so the net effect is a few extra bytes over the wire on DB work you were going to be doing anyway. Critically, this means that anonymous users aren't going to be generating sessions that you have to store and validate on every page with a form (as forms use csrf_token which generates a session!)

2. Additionally, less data over the wire between the app and DB. You're going to have a small list of active sessions; you could enforce that as a to a small number to ensure it stays small.

3. You retain CookieStore's invulnerability to session fixation.

4. No sweeping!

You can still put most of the work on the client, and only keep the verification bits on the server. Of course, the same technique is applicable to DB-backed stores as well, as a means to provide a mechanism for users to manage their sessions.