I believe you are concerned to scale your application in the future if there is expected growth.
The decision on this architecture should be thought of in relation to the maturity of the project itself and utilization growth. You should consider whether implementing a more robust standard initially is feasible for the business - the team for delivering a new product is paramount.
As I told you, each strategy adopted has a related cost.
You can use Nosql with key/value for great performance, but you will have to pay for it.
With SQL (I believe your project should be based on it), you have minimal cost now and if there is scale, using design standards, you can easily turn the key to another more optimized model.
Today, we have various products, with varied performances (Redis, Mongo, Cosmos, etc), each Nosql solution still has a choice of model to use.
If you have a budget and don’t want to save, a key/value standard can be great for this. But if the project is an MVP and will make a market test, reuse the available resources but preparing your backend for change if there is a quick scale.
Don’t forget that in a project that will have high availability, you don’t only need storage technology to scale. Design standards are essential for this task.