None of that has anything to do with the security that SHA256 provides to your application. SHA256 knows how to take care of itself. It doesn't know a damn thing about passwords. SHA256 isn't a secure password hash.
You already know that, because you're not just using SHA256; you're also adding a random salt to it. That's because if you didn't do that, attackers could just aim a precomputed dictionary at your database rows and smite it. So your hash isn't SHA256; it's a construction called "salted SHA256" (or "SHA256 with a nonce").
Nonced SHA256 still sucks, though, because SHA256 is lightning fast. Attackers can't throw precomputed dictionaries at your password hash, because you randomized them. But they can take each hash in turn and run a large dictionary against each hash. This is a brute force attack, but it's not a brute force against the 256 bits of the hash; it's an attack against the (low) entropy of the passwords themselves.
This is how all password cracking got done in the '90s, which was a bit of a golden age for password cracking. It's how John the Ripper (the most famous password cracker) works. John the Ripper is extraordinarily fast against Unix password hashes, which are slower (by a lot) than SHA256. Incremental crackers tear through naked SHA256 hashes like a knife through butter.
That you don't know any of this --- and I say this respectfully --- tells me that maybe you should be using someone else's password hashing library instead of reinventing your own. But you're welcome anyways for the quick and dirty lesson in password hashing.