SQLBlog is a group blog by SQL Server professionals on query tuning, DBA practices, storage, and database hardware.
HN links it in SQL Server discussions, such as a Hugo Kornelis post on passing parameters that was debated against Joe Celko's view.
So here is my take:
I'm currently working on a SaaS product built on .NET running on Windows Server, IIS, and SQL Server. We're not really a "startup" anymore, but we're still very small. I wasn't here when the first version of the product was built so I wasn't part of that decision.
If I were building this product from scratch today as a money-poor startup, I would probably go with tech stack included Java or Python and PostgreSQL. The primary motivation being cost (as in money).
Each developer is technically required to have an MSDN/VS Pro license (renews for just under $1000 per year). This is not very expensive if you're generating revenue, but if bootstrapping it is not cheap. You could cheat and just share a single license; you definitely won't get caught.
Windows Server licenses, compared to other datacenter costs, are relatively inexpensive. Windows Server has a few advantages; particularly in it's easy to administer and there are plenty of sysadmins out there than know it well.
The elephant in the room, at least for a SaaS product, is SQL Server. The features of Enterprise Edition are so compelling for SaaS (HADR, unlimited RAM, online index operations, compression, and encryption) that it's practically a requirement. But this will quickly become one of the most expensive costs in your datacenter.
But in my experience, SQL Server has some real advantages that I haven't yet discovered for PostgreSQL. The "community" around SQL Server is huge and has a ton of…
> I don't think most storage engines actually compress the data
Most major RDBMs (Oracle, MS SQL Server and even MySql) support page level compression.
> because it would slow down reads and writes dramatically
Not really, modern compression algorithms (e.g. zippy) have much faster decompression/compression speed than IO speed even for SSD drives, and having smaller IO traffic due to data compression can make actual performance higher with compression. Also you can fit more compressed data into FS cache, which again reduces IO traffic.
> Page-level compression might be useful, I guess, depending on your use case.
Sure, here are some examples: http://sqlblog.com/blogs/linchi_shea/archive/2008/05/11/sql-server-2008-page-compression-compression-ratios-from-real-world-databases.aspx and http://sqlblog.com/blogs/linchi_shea/archive/2008/05/16/sql-server-2008-page-compression-performance-impact-on-table-scans.aspx
The biggest problem with scalar UDFs is not the IO performance. It is that they force the query to serial (non-parallel). On queries that return a non-trivial quantity of data, that hurts.
https://www.brentozar.com/blitz/blitz-result-user-defined-functions-slowing-down-sql-server/
http://sqlblog.com/blogs/paul_white/archive/2011/12/23/forcing-a-parallel-query-execution-plan.aspx
I'm still very puzzled about these eventually consistent systems… Maybe I'm just getting old…
> Consider Immutable Data
˙ƃuoɹʍ ƃuᴉɥʇǝɯos ƃuᴉop ǝq ʇsnɯ no⅄
Perhaps locking isn't such a bad idea after all?
> De-Normalise Your Data
The more usual advise is to normalize it to the hilt:
http://sqlblog.com/blogs/paul_nielsen/archive/2007/12/12/10-lessons-from-35k-tps.aspx
I've been reading about that too:
http://www.celko.com/puzzles.htm (first part)
vs
http://sqlblog.com/blogs/hugo_kornelis/archive/2007/10/04/how-not-to-pass-a-lot-of-parameters.aspx (Celko replies in the comments)