Tooling and integration are definitely major points. I guess any time you get the whole app stack from a single vendor; you're likely to get a more integrated product (os/400, db2, RPG and green screens; ...maybe not.....:)), while at the same time forfeiting opportunity to pick the individual components that suits you the best. You're obviously more dependent on developments at your vendor as well. So if you believe MS is dying, you should probably choose another database. Considering Word's dictionary includes RPG, yet neither Postgres nor MySQL, that belief might not even be that farfetched:).

Now, for what I am trying to do, easy access to a proven distributed transaction infrastructure is non negotiable. MS provides this. So does Oracle, and certainly IBM. The Java world provides this in spades as well, but I'm not sure how nicely the popular open source db's play along. Last time I looked at Postgres, this seemed at best a medium priority work in progress. Since it doesn't take too many systems left in disagreement about the status of a million dollar transfer to annoy the heck out of some people, in this case I'd rather stick with one of the known entities.

For somewhat similar reasons, I prefer MSSQL's ability to replicate in synchronous mode over the asynchronous / possibly lossy replication that MySQL ships with (.net client auto failover is a nice added bonus). I believe there are add on products for MySQL and Postgres to accomplish the same, but that they are neither free nor used, developed and tested as widely as MS' version.

In addition, MSSQL comes with non rdbms features that Postgres/MySQL lacks. Some of these may have Unix/Linux/open source, or at least Java, competitors/equivalents, but since I intend to use several of them, combined they add a lot of value to Sql Server. For example, a pet peeve of mine is that the root of at least some evil is doing synchronously that which could be done asynchronously (obviously not db replication:)). Since my app is financial enough to 'require' strong transactional support, Service Broker asynchronous transactional message queues alone might have been enough to sell me on Sql Server.

I'm also assuming many end users will be Excel jockeys. Hence, giving them access to slice and dice 'their' data in Analysis Services cubes (still trying to wrap my head around the security implications of this one), and integrate said cubes into their own worksheets, instead of just providing canned reports, looks advantageous. Less work on my part as well:).

And, although I have written my share of database transfer and replication scripts in Perl and Python, the latest SSIS seems a better tool for that purpose. I'm assuming I need to generate reports involving data from multiple outside systems.

Damn, this ended up being a long post. Hopefully some will find it valuable. If nothing else, the pills I popped are finally winning the war against my Saturday 'morning' hangover:).