Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQL Server 2005 vs. MySQL for a startup?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: SQL Server 2005 vs. MySQL for a startup?

#11

Post by kogir »

I chose SQL Server 2005 for Loopt, but that's because at the time I made the choice MySQL didn't meet all my requirements. I should have looked more into PostgreSQL, but didn't.

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 ;)

Re: SQL Server 2005 vs. MySQL for a startup?

#12

Post by dfranke »

It sounds like your dataset will fit comfortably in memcached. Run that on top of whatever DBMS you trust and whose SQL dialect you prefer to work with. For me this means Postgre or Oracle, although MySQL 6 looks promising and I might have to drop my grudge against them once it's released. SQL Server 2005 is very buggy and sooner or later it will bite you in terrible ways.

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.)

Re: SQL Server 2005 vs. MySQL for a startup?

#13

Post by dfranke »

kogir wrote: post #11

I chose SQL Server 2005 for Loopt, but that's because at the time I made the choice MySQL didn't meet all my requirements. I should have looked more into PostgreSQL, but didn't. 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 affe…

> If you go with MySQL or PostgreSQL, be prepared to fix bugs in the ADO connectors from .Net to the database.

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.

Re: SQL Server 2005 vs. MySQL for a startup?

#14

Post by kogir »

dfranke wrote: post #13
kogir wrote: post #11

I chose SQL Server 2005 for Loopt, but that's because at the time I made the choice MySQL didn't meet all my requirements. I should have looked more into PostgreSQL, but didn't. 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 affe…

> If you go with MySQL or PostgreSQL, be prepared to fix bugs in the ADO connectors from .Net to the database. 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.

If you find a legitimate bug in SQL Server, you can open a support ticket, and Microsoft will fix it. Frequently these fixes will make it into the next service pack, or if they're severe, a Windows update. This is all at no (extra) cost to you.

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.

Re: SQL Server 2005 vs. MySQL for a startup?

#15

Post by kogir »

kogir wrote: post #11

I chose SQL Server 2005 for Loopt, but that's because at the time I made the choice MySQL didn't meet all my requirements. I should have looked more into PostgreSQL, but didn't. 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 affe…

Before I get raked over the coals:

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.

Re: SQL Server 2005 vs. MySQL for a startup?

#16

Post by henning »

If speed is the overriding concern, see if you can use Berkeley DB, which has ACID transactions and blows away all relational databases in speed. It sounds like your data model may be simple enough for it.

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.

Re: SQL Server 2005 vs. MySQL for a startup?

#17

Post by dfranke »

kogir wrote: post #14
dfranke wrote: post #13

Earlier quoted context omitted.

> If you go with MySQL or PostgreSQL, be prepared to fix bugs in the ADO connectors from .Net to the database. 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.

If you find a legitimate bug in SQL Server, you can open a support ticket, and Microsoft will fix it. Frequently these fixes will make it into the next service pack, or if they're severe, a Windows update. This is all at no (extra) cost to you. 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.

I don't think I ever encountered a bug for which I'd be able to write a coherent support ticket. They tended to be horrendous mandelbugs that were difficult to reliably reproduce due to caching. If it were an open source project then I could have at least set some watchpoints and sent a useful backtrace, but with closed source, SOL.

Re: SQL Server 2005 vs. MySQL for a startup?

#18

Post by especkman »

xirium wrote: post #2

MySQL Server is cheaper and faster. However, MySQL Server is technically only free if you use it with GPL2 applications or never distribute your app.

I think the key is the meaning of the word "distribute." I believe it is generally accepted that using MySQL in a web based application provided as a service doesn't constitute distribution (though there are some questions about situations when the app is hosted on servers operated by a 3rd party).

Re: SQL Server 2005 vs. MySQL for a startup?

#20

Post by ubudesign »

mysql on linux is better then its windows version. and the windows version I belive has a licensing cost. I guess they call it mysql-max and mysql-nt maybe this was the older versions..

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 :)

Post reply on HN