Is MD5 considered insecure?
MD5 for passwords
Using salted md5 for passwords is a bad idea. Not because of MD5's cryptographic weaknesses, but because it's fast. This means that an attacker can try billions of candidate passwords per second on a single GPU.
What you should use are deliberately slow hash constructions, such as scrypt, bcrypt and PBKDF2. Simple salted SHA-2 is not good enough because, like most general purpose hashes, it's fast. Check out How to securely hash passwords? for details on what you should use.
MD5 for file integrity
Using MD5 for file integrity may or may not be a practical problem, depending on your exact usage scenario.
The attacks against MD5 are collision attacks, not pre-image attacks. This means an attacker can produce two files with the same hash, if he has control over both of them. But he can't match the hash of an existing file he didn't influence.
I don't know if the attacks applies to your application, but personally I'd start migrating even if you think it doesn't. It's far too easy to overlook something. Better safe than sorry.
The best solution in this context is SHA-2 (SHA-256) for now. Once SHA-3 gets standardized it will be a good choice too.
To complete @CodesInChaos' answer, MD5 is often used because of Tradition, not because of performance. People who deal with databases are not the same people as those who deal with security. They often see no problem in using weak algorithms (e.g. see the joke of an algorithm that MySQL was using for hashing passwords). They use MD5 because they used to use MD5 and are used to using MD5.
Performance is much more often discussed than measured; and yet, logically, there cannot be a performance issue if there is nothing to measure. Using one core of a basic CPU, you can hash more than 400 MBytes per second with MD5, closer to 300 MB/s with SHA-1, and 150 MB/s with SHA-256. On the other hand, a decent hard disk will yield data at an even lower rate (100 to 120 MB/s would be typical) so the hash function is hardly ever the bottleneck. Consequently, there is no performance issue relatively to hashing in databases.
The usual recommendations, for hash functions, are:
Don't do it. You should not use elementary cryptographic algorithms, but protocols which assemble several algorithms so that they collectively provide some security features (e.g. transfer of data with confidentiality and integrity).
Really, don't do it. For storing passwords (more accurately, password verification tokens), don't make a custom mix of a hash function and salts; use a construction which has been studied specifically for such a use. This normally means bcrypt or PBKDF2.
If a hash function is indeed what does the job, then use SHA-256. Consider using any other function only if some serious problem with SHA-256 (most probably its performance) has been duly detected and measured.
I'm using salted hashes currently (MD5 salted hashes).
If you are salting MD5 hashes, you definitely don't want to be using MD5. It sounds like you need to use PBKDF2 or bcrypt.
As far as I know it's always been the algorithm of choice among numerous DBAs.
That's not a compelling reason.
I have worked with a lot of DBAs that are at least 5 years behind in general technology (not using version control, unformatted perl scripts for everything, etc). They might have been particularly bad DBAs, but I think it comes with the extremely conservative mindset of not changing things.