13 million rows is 500GB?! You must have HUGE tables--that's 38KB/row! You must mean 13 Billion rows or 500MB?
I've been running a database that has grown from 500GB a few years ago to 1.5TB+ now. If your server has plenty of RAM, any popular brand of SATA SSD with sufficient capacity should be plenty for your use case (if your cache hit ratio is less than 99% what you really need is more RAM, not more raw disk performance). In a properly configured database server, the data drive spend most of their time writing, not reading (because reads can be cached--writes cannot). If you have the money and time spent replacing bad drives is more important than cost, just get the one with the best warranty (though to be honest, I've used both cheap desktop and mid-range enterprise SSDs and had very similar failure rates).
You most likely want to use a mirrored set for redundancy (this would have applied to HDDs as well), and possibly database mirroring as well (depending on your desired disaster recovery point and time).
Depending on how hard you hit them, you may also want separate volumes for the tempdb and for log files (HDDs are usually fine for logs, though, as they do very little random access).
When you need even faster performance, adding more drives to a RAID 10 volume will give it to you, up to the limit of what will fit in your case and attach to your controller(s). When you exceed that, you can switch to Fusion IO or similar ultra-high performance caching, or to external massive SAN RAID systems, which can also use SSDs and scale pretty much as far as you have money for.