The OAuth2 standard defines another approach to this problem, and that is to use the token revocation and token introspection endpoints.
The revocation endpoint is described in RFC 7009, e.g.
This revocation mechanism allows a client to invalidate its tokens if the end-user logs out, changes identity, or uninstalls the respective application.
The introspection endpoint is described in RFC 7662, e.g.
This specification defines a protocol that allows authorized protected resources to query the authorization server to determine the set of metadata for a given token that was presented to them by an OAuth 2.0 client. This metadata includes whether or not the token is currently active (or if it has expired or otherwise been revoked)
But, yes, this probably implies storing the tokens (or a reference to them) in a database somewhere. It might also mean that you don't need to use JWTs but can instead use opaque reference tokens. Here's a good post on the trade-offs, e.g.:
Reference tokens (sometimes also called opaque tokens) on the other hand are just identifiers for a token stored on the token service. The token service stores the contents of the token in some data store, associates it with an infeasible-to-guess id and passes the id back to the client. The recipient then needs to open a back-channel to the token service, send the token to a validation endpoint, and if valid, retrieves the contents as the response.
A nice feature of reference tokens is that you have much more control over their lifetime. Where a self-contained token is hard to revoke before its expiration time, a reference token only lives as long as it exists in the STS data store.