Best practices on data modelling in Vault

On the project we are planning to use Vault to store dynamic secure credentials.

Right now we are using RDBMS and the entity we are storing, apart of credentials also contains useful metadata, so the question here would it be OK to migrate the whole entity to Vault?

Doing it this way would reduce handling consistency issues between RDBMS and Vault.

What are possible issues with storing the whole entity in Vault?

lets say I have the following entity:

    secret: string
    id: string
    lets say there are 4 string fields here
    jsonData: string

My question would be is it ok to use Vault more as a database than secret storage for such case and what kind of concerns should I foresee and how to handle those?

Total size of entity will not be larger than 10KiB.
Total count of entities will not exceed 1500 in any foreseeable future.

The question is to loosely defined to be able to answer. A concrete example may help clarify it.

updated my question with example model and some estimations on the expected number of entities

Thank you for your edit.

The approach you describe sounds fine to me, but you should be aware of this caveat: if you store secret data and less confidential metadata at one single path in a Vault KV store as a single JSON object, you will be unable to permission users to read the metadata, but not the secret.

Perhaps this is fine for you - but if it is not, you need to divide the secret and the less confidential data into two JSON objects stored at separate paths in Vault.

FWIW, you can define custom metadata on KV secrets that may help provide the potentially needed separation that @maxb is referring to.