Try a commerical database, such as Microsoft SQL Server (FD: I work there as a developer). To bring up a recent example, it can build indexes without locking the whole table so you wouldn't need to jump throught the hoops like the FriendFeed guys just did with MySQL. Unless your time is free it will cost you less to buy SQL Server than to write your own "online index thingie" on top of MySQL.
And if your time is free, then you are probably a startup and you can get SQL Server and bunch of other MS tools for free via http://www.microsoft.com/BizSpark/
MySpace runs on SQL Server: http://www.sqlservercentral.com/blogs/steve_jones/archive/20... and if it's good enough for them it will likely be good enough for your site as well. I'm not sure if the scale-out story is any good (there are "partitioned views" which are basically "sharding" but I never used those), but scale-up story is as good as they come - it can efficiently utilize 64-cores of the HP superdome.
I don't know much about Oracle and IBM DB2, but I know that the latter has a free version without too many restrictions on it, so give them a spin as well. If ease of use is importnat to you, common wisdom has it that Microsoft's is the easiest to use among the top commercial vendors. NB: I did not verify the common wisdom, YMMV :-)
You're suggesting to use a commercial database but don't provide any reasons beyond what free databases can do.
PostgreSQL is pretty much on par in terms of features and performance with SQLServer and Oracle. So if you're looking for a free solution to roll your own then look no further.
The only reason I can see for going with a commercial DB is when you not only want commercial support (you can buy that for Postgres, too) but a shrinkwrapped "don't bother me"- solution with SLAs etc. Be prepared to pay through your nose for that, though.
In terms of usability there is no big difference between any of the commercial or non-commercial offerings. They all have their special peculiarities (which is why you always hire a DBA who is familar with your RDBMS, not just with "any" RDBMS) and the shiny GUIs that some of them provide are not normally of interest in day-to-day work.
Comments
Try a commerical database, such as Microsoft SQL Server (FD: I work there as a developer). To bring up a recent example, it can build indexes without locking the whole table so you wouldn't need to jump throught the hoops like the FriendFeed guys just did with MySQL. Unless your time is free it will cost you less to buy SQL Server than to write your own "online index thingie" on top of MySQL.
And if your time is free, then you are probably a startup and you can get SQL Server and bunch of other MS tools for free via http://www.microsoft.com/BizSpark/
MySpace runs on SQL Server: http://www.sqlservercentral.com/blogs/steve_jones/archive/20... and if it's good enough for them it will likely be good enough for your site as well. I'm not sure if the scale-out story is any good (there are "partitioned views" which are basically "sharding" but I never used those), but scale-up story is as good as they come - it can efficiently utilize 64-cores of the HP superdome.
I don't know much about Oracle and IBM DB2, but I know that the latter has a free version without too many restrictions on it, so give them a spin as well. If ease of use is importnat to you, common wisdom has it that Microsoft's is the easiest to use among the top commercial vendors. NB: I did not verify the common wisdom, YMMV :-)
You're suggesting to use a commercial database but don't provide any reasons beyond what free databases can do.
PostgreSQL is pretty much on par in terms of features and performance with SQLServer and Oracle. So if you're looking for a free solution to roll your own then look no further.
The only reason I can see for going with a commercial DB is when you not only want commercial support (you can buy that for Postgres, too) but a shrinkwrapped "don't bother me"- solution with SLAs etc. Be prepared to pay through your nose for that, though.
In terms of usability there is no big difference between any of the commercial or non-commercial offerings. They all have their special peculiarities (which is why you always hire a DBA who is familar with your RDBMS, not just with "any" RDBMS) and the shiny GUIs that some of them provide are not normally of interest in day-to-day work.