There are rainbow tables, and there is brute force... these are two distinct things.
A rainbow table is a special case of a big precomputed table of hashed passwords. As such, a rainbow table can "invert" a hash, i.e. recover a matching password, only if, at some point during the table construction, that password was considered and hashed. Correspondingly, if a password can be found with a rainbow table, then it could have been found with a simple dictionary attack which would have cost no more than the table building. The "rainbow" does not change that; in fact, the rainbow thing actually makes the table more expensive to build, by a factor about 1.7 (that's because the table construction tends to consider and hash several times the same passwords, and that's rather unavoidable).
A consequence is that no rainbow table is worth the effort unless it can be applied at least twice. We use salts precisely to prevent that from happening. The salt can be viewed as making a variant of the hash function, each new salt implying a new variant. A precomputed table is worth anything only if it was precomputed with the same variant (the same salt) than the hash value which is to be attacked. If no salt value is used more than once, then the intelligent attacker will not waste his time building Kleenex rainbow tables; he will just run
a dictionary attack.
We consider that the attacker knows the salt. Why ? Because the server knows it, and the attack model is that the attacker could obtain a dump of the server database. Whatever the server knows, the attacker knows too. Thus, when attacking a hashed password, the salt length or contents do not matter (the attacker must include the salt value in his computations, but no salt length will make his task easier or harder).
Thus, we only have the password as line of defence. If we want to know how much the attack costs, then this becomes economics, and, as such, some complexity arises. In particular, we want to know if we are talking about an attacker who is after one very valuable password (say, the password which protects the main computer of the alien force which is about to obliterate Earth), or an attacker who makes a living out of breaking many passwords. In the latter case, the hardware costs become negligible with regards to power consumption.
If we take @jimbob's estimates, hardware which computes 109 hashes per second uses 200W worth of power, and power comes at $0.1 per kWh (note that power cost includes cooling: every Watt spent on computation also becomes heat, which must be somehow dissipated). This gives us 1.8*1014 hash values per dollar. From that, we obtain the following:
With $10K, an attacker can try 1.8*1018 hash values, which is more or less the number of possible passwords of 10 alphanumeric characters (uppercase, lowercase and digits).
With 683.7 billions of dollars (that's the total US military budget in 2010), an attacker could try about 1.23*1026 hash values, corresponding to about 14.5 alphanumeric characters. Let me add that this figure corresponds to the yearly output of about one hundred nuclear power plants, so that cracking effort would hardly be inconspicuous.
Conclusion: with 15 random alphanumeric characters, your passwords will resist even implausible enemies, even if you totally botched the hashing by using a single invocation of SHA-1, instead of using bcrypt or PBKDF2 with a high iteration count, as you should do. Note that this is valid only for random characters, not at all for the kind of characters you may come up with in the privacy of your brain. Human brains are not good at all at randomness.