There's two parts to this question:
Where should the data be persisted permanently?
Let's hold off on that part until we answer the second one, which is much more important:
Where should the clients query to check for vulnerabilities?
A caching layer. Your clients should never hit the underlying data store first. There's not a need for atomic transactions here, and your queries would be fine dealing with data that's a few seconds, a few minutes, or perhaps even a few hours old.
For that caching layer, you can use things like Redis, Memcached, Elasticache, or whatever in-memory store is available at your chosen cloud provider.
Your app should check the cache first, and if the required listing isn't in cache, query it from the database, and then populate it into the cache along with an expiration date. This logic should be built into your app, not into the data persistence layer or the caching layer.
Now, back to that first question: where should the data be persisted permanently? Once you design the app to check the cache layer first, you can see why the persistence layer isn't quite as important of a decision. It's easy to scale a caching layer to thousands (or hundreds of thousands) of concurrent connections.
The answer: use the database you're already comfortable with, and start getting comfortable with a caching layer.