Separate database for users and sessions?

[mumingpo]

Canonically, I have 3 types of data in my app:

1. User sessions: Key-value pair data, read extremely frequently (every authorized action), updated often (to extend expiration time), and does not require persistence (worst case: user have to login again). The ideal database for this would be an in-memory database instance like Redis.
2. Core user data: Relational data, read frequently, updated often, and requires persistence and replication. The ideal database for this would be a SQL database.
3. Large user records: Key-value data, rarely read, immutable, and requires persistence and replication. The ideal database for this would be an UUID record in a SQL database followed by an UUID indexed storage service like S3.

So it seems to me that next-auth is trying to manage 1 and 2 at once, storing sessions and core user data in the same database. However, it may be desirable to separate the sessions and core user data into two separate databases.

This will:

1. Reduce the latency for using relational database for session data.
2. Reduce the storage cost for using in-memory storage for core user data.

I do not have experience in cloud architectures and I am unsure how significant the cost and benefits are. However, having session data stored separate from relational data seemed to be a good practice to me. Is this practice on the road map to be supported in the future, or are the benefits not significant enough to be an issue, at least until the application grows to a very large scale?

[ThangHuuVu]

This is not on our roadmap AFAIK, but still an exciting idea.
For now, if you want to reduce the I/O of DB, you could store only the Account and User and use JWT for Session. See: session.strategy