In almost all projects, the choice of the database system is 'almost' automatic .. if you're coding "in the Microsoft stack" you'll go with SQLServer, in the Linux world the default is MySQL, and for corporate in-house project most shops have decided on some default like Oracle or IBM DB2.
What are your thoughts?
My customers often stipulate what database engine we will be using. We write .net apps against non-SQLServer dbs regularly. In the long run, it's better for the customer because they get to maintain what they know.
I work on a gov contract, and while we code in the "Microsoft Stack", we can't use SQL Server because the government gets Oracle for free and wants us to use that instead.
I tried all three approaches. I still use MySQL for web sites, but for in-house projects I rather choose Firebird or Postgres.
The reason is that they are free (both as in beer and speech), much less bloated (Firebird installer is just few MB, for example) and still do the job very well.
The main benefit you get is that the same thing scales from embedded to enterprise level, so there's no "first try is free, but you'll pay a lot later" kind of story behind it. I've seen Firebird databases of 200+ GB working just as fine as 1MB one in an embedded application I make.
Most environments in which I have worked have used a variety of stacks. I have not seen any "stack lock in" effect to any great degree. The Microsoft stack does favor SQL Server when no other spec is given and LAMP favors MySQL but I don't see it as being that strong of a bond. The three main firms where I have worked this past several years:
Medical Software Firm: ASP.NET C# Stack on IIS with MySQL Investment Bank: Java on *NIX with Sybase, Oracle and DB2 Major Software Vendor (and one of the major DB vendors mentioned here!!): Java on RHEL with PostgreSQL
I think that most good shops evaluate their needs on a project by project basis and don't choose database products solely on their stack integration. If this were so, Oracle would not be the largest DB maker and DB2 would be much smaller than it is.
Maybe its about comfot. MS SQL Server Express edition comes attached with visual studio so it's easier to set up an application to work with SQL Server. People using linux are used to install MySQL, SQLite or PostgreSQL in a second, and maybe that's beacuse they don't need windows to run a DBMS. Corporate projects is another story, there should be no comfort and look for DBMS features.
Those seem to be the logical choices if the client or shop has no preference. If you're not 100% sure of the deployment environment it's a good idea to test your application against multiple databases to insure what you're not using any special features of one particular database. If you do decide that you must use a special feature that 'locks' you into a database it's best that you know about it early and have made an informed decision rather fall into the trap of using a feature that unknowing locks you into a particular database.
I don't know that I agree that the choice is so cut and dry in the Unix world. Postgres and MySQL go toe to toe all the time and the choice is not as clear as you made it seem. That said, their are plenty of other db's on Unix that are used (for example, sqlite powers many embedded systems and even has a place on the desktop (in Fedora's YUM package configuration utitlity, for example)).
It will depend on what types of projects you pursue, and what platforms are acceptable to the enterprise using the technology.
Good database design - 3rd normal form - will be the criteria against which you will be judged in most cases. Larger enterprises may force you to use Oracle with the MS stack. Mid-sized businesses will more than likely use SQL Server, but if they are consumers of demographic data from sources such as Claritas you'll get Oracle bundled with the application.
From the perspective of an employer locating someone with a skill set, MS SQL server is more prevalent with the businesses that have an in-house development dept.