Provided you are properly using a NIST-approved authenticated encryption mode (such as AES-CBC & HMAC-SHA with proper KDFs & IVs, e.t.c.) breaking this should be as difficult as simply breaking an encrypted file. Now, depending on your use case this could/could not be enough. I will take you through a couple of other options I myself can think of, as well as the potential security benefits/drawbacks it may offer.
Option 1: Standard authenticated encryption with encrypted private key stored in DB
This (as mentioned before) will be security-wise just as good as encrypting a file in the same way, and should be as hard to break as the underlying encryption. However, it offers one major drawback: this allows an attacker to destroy/irreversibly modify the private key data, because this simply is not part of the encryption threat model (it only cares that the data is secret and cannot be modified without being detected). This is where I propose solution no.2:
Option 2: DERIVE the private key using the user's password
This option is involves (basically) feeding your derived key into a PRNG and generating the private key every time (whenever you need the private key, you just derive it from the user's password), this has the advantage of
- not even being stored in the database,
- the private key (obviously) cannot be corrupted now, because it is not stored anywhere.
However, this option may be a little more risky than option 1 because of two reasons:
- PRNGs are generally considered inferior in terms of security to block ciphers (such as AES)
- Depending on your choice, a brute-force attack on the underlying password MIGHT be faster than trying to break AES
- The number of possible private keys is now inevitably much shorter (due to the nature of a psuedorandom number generator).