Ultimately depending on the type of service, you will probably end up with a mix, where some of the data is always pulled from the database and some of it is retained.
Example:
User Presence is not reliable when only relying on the database, when a server goes down in a not-so-graceful way, you cannot rely on the database being up to date. For volatile data like this, you either set TTLs on DB records and then you have a delay between when all the users are reported as offline, or you retain the presence in memory realtime so you can report accurately at a given moment.
For data that is reliable when only relying on the DB, it should be done that way, so you can depend on an ACID compliant solution for state, rather than hoping the memory isn't inaccurate. Traffic on the DB is much more efficient than you think, and you can scale your DB in most cases you might not have the ability to scale the app when the state becomes unmanageable.
Ultimately depending on the type of service, you will probably end up with a mix, where some of the data is always pulled from the database and some of it is retained.
Example:
User Presence is not reliable when only relying on the database, when a server goes down in a not-so-graceful way, you cannot rely on the database being up to date. For volatile data like this, you either set TTLs on DB records and then you have a delay between when all the users are reported as offline, or you retain the presence in memory realtime so you can report accurately at a given moment.
For data that is reliable when only relying on the DB, it should be done that way, so you can depend on an ACID compliant solution for state, rather than hoping the memory isn't inaccurate. Traffic on the DB is much more efficient than you think, and you can scale your DB in most cases you might not have the ability to scale the app when the state becomes unmanageable.
Think of it as RAM vs ROM, RAM is volatile, so if you need stability and accuracy of data, RAM is not the right way to go about it in most cases.