MySql gets its speed rep from the 'MyIsam' table type. But you don't want that for financial data. You want a stronger database. They have another several table types that are more robust and standardized, but not as fast.

Postgresql is plenty fast for large installations when well tuned. And it has good referential integrity, a long-enough history so you can trust it, and stored procedures. MySql is simpler to get started with.

I've never heard that SQL Server was faster, but I'd estimate they have very nice integration with .NET, as it's the same company. This nice integration will undoubtedly lock you in to using their database forever, though. And who knows how their price will change?

Whichever you choose, you will gain if you have at least one person around who has used the DB before and (for MySQL) table-type before. Even once in a while.

Paid consultants are available for any database you choose.

Have you considered an Action Pack subscription? If not, you might want to check in to it: https://partner.microsoft.com/Indonesia/program/managemember... You get a +lot+ of MSFT software for around $300 bucks. Granted, the license is only for two years, but that should be enough to get a startup off the ground. If you don't have enough money to buy MSFT licenses after 2 years, you have bigger problems than licensing costs.

And, as long as you're willing to keep going the MSFT way, there's ways to get cheap bulk subscriptions to MSFT licenses. You just have to keep up with MSFT certification process. They actually make it pretty easy to start your own software company based on the MSFT stack.

I really can't speak to speed of SQL server vs MySQL, however. It sounds like most of the data in your DB is going to be text based. I'd be a bit more concerned about speed if you were going to be serving video or a lot of graphics out of your DB.

One option that you might consider before investing a year or two an a DB, is downloading a trial version of each RMDB and do some tests.

MSSQL Server 2005 download: http://msdn2.microsoft.com/en-us/bb498185.aspx

MySQL 5 download: http://dev.mysql.com/downloads/mysql/5.0.html#downloads

Your schema sounds pretty simple. So, design your schema, and run some tests. Find out how quick your server will run with each DB. I bet if you spent a week or two running tests like that, the time spent would more than pay for itself in the long term. Platform and DB choices tend to lock you in for a long time, and if you hate your platform, those are headaches you'll have for quite a while.

Bear in mind when you take this advice that the DBMSs I dislike the most are also the ones I have the most experience with, so it's possible that Postgre and Oracle are just as bad, and I just haven't discovered it yet :-)

Don't store technical indicators in your database; compute them on-the-fly. Memoize them if necessary, but it's probably better not to since I don't think you'll be CPU-bound and the added latency will be negligible.

If you're dealing with live quotes, don't store them in your database. Just keep them in memcached and re-fetch them if your server goes down. Do all your DB writes at once, at the end of the day after the market closing bell. (Aside from user-specific data, which obviously needs to be committed immediately.)

You should also consider a mix of both; you could use BDB as a kind of cache used for rapid delivery whereas, say, the relational database could be used for non-time-critical processing and storage or something.

Do you have any SLA/other constraints on how fast you have to deliver financial data?

In your case, it sounds like MySQL should work just fine. For fast response times, just partition the data across a lot of cheap servers that can keep it all in RAM. This approach lends itself to a free database. That said, speed will be affected much more by what pre-processing you do before inserting the data (to optimize lookups), and how you design your schema than by your database vendor choice.

If you go with MySQL or PostgreSQL, be prepared to fix bugs in the ADO connectors from .Net to the database. I've used PostgreSQL with .Net and npgsql needs some work. Perhaps MySQL connectors are better.

I'd start with PostgreSQL or MySQL and only switch to SQL Server 2005 if you run into problems. The switching cost won't be that high if you don't use stored procedures and stick to using ADO.Net generic functionality.

Microsoft has been a great partner and their licensing model hasn't caused us any problems, so don't be afraid to go with them if they're the right choice. You'll take some heat for it though ;)

Likewise for SQL Server and ODBC, but then the bugs are in SQL Server so you can't fix them. However, .NET has a perfectly good ODBC client library. Use that, not ADO, to talk to MySQL.

In speed tests I've seen using ODBC be as much as 10x slower than npgsql in talking to PostgreSQL. I didn't look into why, and just used ADO.Net.

Google for ODP.NET. If it's anything like as good as their pure Java JDBC drivers, it will perform pretty well.

npgsql is great. It is up to 10x faster than the PostgreSQL ODBC driver for our workload. It has a few tiny issues that are irritating but not big problems, and I plan to fix them and submit patches when I have time.

Non-speed issues: 1. Sql Svr 2000 had locking problems such that many transactions deadlock and automatically get rolled back. This was due to page locking. I think MS fixed this in 2005 with record-level locking. 2. Sql Svr has very nice stored procedure support. This can be extremely useful. If you think you may need this capability, then Sql Svr is the better choice.

If you do decide to go with Sql Svr, you will probably end up having to get a copy of VS 2008 and do some C# programming. It's almost impossible to maintain Sql Svr w/o it, unless you want to maintain the db by hand every day.

It doesn't sound like you have much db experience. Get a couple of experienced db admins in to talk with you before you make any big decisions, even if it's just a two hour consult.

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.

For $42 from Amazon you can get the SQL Server 2005 developer version, which is the "enterprise" version, but just for development to get you started http://www.amazon.com/Microsoft-SQL-Server-Developer-2005/dp...

Personally, I am sticking with MSSQL 2000 because I know and already own it. You can get that on eBay for about $800.

I hate that I tend to get out of date on Microsoft stuff, I tend to stick with what I have and not experiment once something is working the way I want it. I did buy the MSSQL 2005 developer because the price is right, one day I will try it out.

If you're worried about the MySQL license, you should try PostgreSQL. I've been using it for three years and have had nothing but extremely positive results. Version 8.3 is stupidly fast.

I'm a big fan of PostgreSQL but based on your description you might want to look into one of the existing kdb solutions from www.kx.com. Those guys have been solving stuff in that ___domain for the last two decades.

If you have special requirements, such as true isolation in transactions, be aware that this is "leading edge" for SQL Server 2005, and probably for MySQL. On the other hand, Oracle has been doing it for years.

If the data is being streamed in, and timestamped, and stored, you may want to just hold it in memory (32 Gigs holds a lot of data) or write to flat files. For simple data types, that are used in a predictable way, not much beats well-written custom code.

what about couchdb? Still young but can be clustered and will probably way outperform any relational db for the stuff you're describing.

Last time I did benchmarks (a few years ago) mssql totally blew away mysql and postgres on windows. Turns out this was b/c I was using a "dependent subquery" which in my opinion is a lot simpler way to write a lot of queries.

Now that I use mysql (and linux and solaris) exclusively I don't use dependent subqueries at all and all is well.

I have never had any speed problems. Also if you are going to use asp.net membership stuff it makes sense to go with it. There is a mySQL membership provider but its not great from my playing.

Also the cost is not going to be that much because you can do an aweful lot of processing with one MS database server.

I am sure with some googling you can find some bench marking of all major dbs.

I use discountasp.net for my .net apps as a starting point.

One last thing, finding someone to work on your MS sql database might be easier.

Speed is really not a concern anymore because you can use memcached or other distributed cached system when you really need that much scalability and fast access to raw data.

if you are going with .net then your server I guess is a windows server so go with MS SQL..

I would not go with.NET Unless other things depended on it and there was gun pointed at my head :)