Skip both of them.
Just use memory with a (very frequent) periodic write of the entire dataset in a file named after the time you saved it. Just write/read a block of memory (big array) to/from disk in a file named after the relevant time. What's better is that modifying or accessing this data is normal straightforward memory accesses - very likely less work than writing SQL queries and very very likely easier to unit test. So this should not only be faster, it should also take you less work.
You probably only care about ~10,000 US stocks & bonds, maybe 50 numbers per, all of which are represented well by a 64-bit double (most probably fine in a 32-bit float... yes even US bond prices - they trade in 32nds - binary works fine). 10,000 instruments x 50 numbers x 8 bytes = 4M bytes. All 3 dimensions could increase by an order of magnitude and the answer would probably remain the same or very similar.
You mentioned two requests, and a primary goal of SPEED.
1. Data for a stock/bond - it's in memory. Heck, there's a good chance you can fit the entire current dataset in your CPU cache. You just can't beat that (well you don't need to - put down that VHDL tutorial).
2. Data for a certain day/time (across a bunch of stocks): Just read the file off disk for that day/time. Even if this isn't immediately up to your needs, normal optimizations should buy you tons of performance here - buy RAM and disk mirrors. The data should be contiguous on disk, so you should have very minimal seeking (which is normally the speed killer). You could come up with something that beats this by pulling out fewer than all the stocks at once, but your complexity would skyrocket. This will should at least beat most setups with MySQL or SQL Server 2005 without a metric ton of tuning.
I'm guessing you forgot to mention that you need a time-series for price and volume information (if only for a graph to throw up alongside some boring numbers). Consider just handling that separately, especially as all the other numbers you're interested in don't change anywhere close to as often (and those that do are based off the price/volume and can be trivially calculated on the fly). Some headaches to watch out for though: if you try opening 10,000 file handles at the same time, something's likely to get mad at you. Also note that if you're thinking of opening and closing 10,000 files a lot, you're likely going to be sending the disk seeking around like crazy updating meta-data on disk.