I'm not fanatic on any database but I wish to see differences between vendors.
For instance, I use mostly Oracle and I see that others (MySQL, SQL Server, PostgreSQL, ...) cannot do:
The same for SQL Server, that others cannot do:
Differences depend on your intent--unless you really want just an exhaustive laundry list. In other words, it appears that you really mean to ask about significant differences, and significance varies by intent.
I suggest that most people typically find several specific things to be significant:
The relative significance of these database characteristics seems to vary primarily based on whether one's intent resides within programming in-the-large or in-the-small. Since I mostly work in the world of programming in-the-large, I will speak from there. When I work (typically on my own projects) in the world of programming in-the-small, I usually still lean towards my decisions for the world of in-the-large since I find it easy enough and I prefer to save myself from the headaches of changing my mind later when my project grows up. I have noticed that many open-source projects suffer huge, sometimes fatal, growth pains when their following forces them to cross the threshold from in-the-small to in-the-large.
My first concern is that I must always be able to change my mind about my choice of database vendor and product, so compatibility is king and portability is queen. With that in mind, I strongly prefer to treat the database as a storage medium only, so I avoid putting any code into the database and I avoid any features that are not relevant to storage or are specific to a vendor or product. For a RDBMS, compatibility primarily means ANSI SQL standard compliance, so I immediately reject any product that is not reasonably compliant. Since I work in the worlds of Linux, Unix, and Windows, portability means availability on all those platforms.
My code belongs together and in the best environment for it--not separated into the crippled