The basic pattern you describe is basically the simplest way to create a stateful session management system. Your users would get an opaque session Token (a securely-random string of at least 128 bits in length), usually set in a Secure-flagged cookie. Typically you'd then have a table that stores active Sessions, with the session Token as the primary key, and foreign keys pointing to your Users table (plus any necessary metadata, such as session expiration data; don't rely on the cookie going away when it's supposed to). This is, of course, assuming you can't just store the sessions in memory (perhaps they're very long-lived, or need to be stored across servers), and has a substantial performance impact (lots of database calls) so usually you'd use a lot of caching.
If you want to use this model but prevent an attacker who successfully read your Session table from impersonating the active sessions, you can do that by running each Token through a hash function (such as SHA-256*) before storing it in the database (or looking it up in the database). That makes it still possible to quickly check for a given Token in the database, but makes it practically impossible to go from seeing the database to knowing the valid Tokens.
*It is fine to use a fast hash here (unlike for passwords), because the input string is already too high-entropy for an attacker to brute-force search for it. Similarly, you don't need a salt (although adding one won't hurt anything except some performance) because 2^128 is far too large a number for a rainbow table.