JWT tokens cannot be revoked easily unless you check the token against an online database.
However, one option that you can use with JWT is instead of storing active tokens in the database, the database can store revoked token instead.
Storing a list of revoked tokens instead of active tokens has the benefit of making your revocation database being much smaller and simpler than if you store active tokens, so the revocation list can just be stored (and cached) in-memory or with an adjacent in-memory database like Redis. You can imagine a distribution mechanism in which a relying party that needs immediate revocation can subscribe to be notified by the auth/identity server whenever a token is revoked.
The smaller size of revocation list can make it easier to scale out a revocation database compared to active session database. The downside of keeping a revocation database is of course that you lose two of the biggest advantage of JWT, which is simplicity and the ability to verify tokens offline, so this kind of revocation mechanism is rarely used.
The only place where I've seen revocation list is widely used is x509 certificate (i.e. certificate used for TLS connection and S/MIME emails). x509 is not exactly the same as JWT, but x509 uses a signed token authorisation/certification that is functionally quite similar to JWT. In fact, x509 actually has three revocation mechanisms: CRL, OCSP, and Certificate Transparency Log, all of which can have parallels to how you'd implement a revocation mechanism in JWT.