What happens to auth.sessions / refresh_tokens on the server?

[hyperknot]

I'm trying to understand persistence Supabase Auth in this discussion: #11100

So far it's quite lonely, I'm only answering myself. One question I cannot find an answer to is what happens with the auth.sessions / refresh_tokens on the server?

• If these are cleaned up at regular intervals, when exactly and how can we control this? This would be pretty much the most important setting on the dashboard, much more important than the "JWT expiry limit".

• If these are not cleaned up then how do people use Supabase in production? I mean these tables would grow indefinitely with mostly useless leftover data. Over time, performance will degrade and you'll pay for this in storage costs.

Can someone from Supabase comment on this? I've spent a few hours debugging the client behaviour on my own, it'd be so nice if someone could shed some light on the server part.

[hf]

Hey @hyperknot,

We have a PR open to deal with this supabase/auth#875. It should be going in fairly soon.

We use GoTrue for app.supabase.com and aside from having somewhat large storage we do not experience any performance issues because of the large tables. In general you shouldn't worry about an implementation detail like this for your app.

I'll transfer this issue to the main Supabase repo and convert it as a discussion.