Unless there is a very specific and valid reason I never try to make applications database agnostic, but my designs usually are to some degree. I do like to av

Unless there is a very specific and valid reason I never try to make applications database agnostic, but my designs usually are to some degree. I do like to avoid features when I know they are non-standard and other options/designs exist which are more standard. In the past on projects that has meant we wrote a bit more code a few times but it has paid off every time. At least what I have found generally is features which have no common analog in other systems are originally added for an Enterprise client and so the stability, integration and support are much less friendly to work with, so avoiding them is just smart IMO. Of course, once those features hit mainstream and other systems mimic them then obviously things change. But in most cases we used "special" features where they just made life easier, better or both, a good example of this is back when SQLServer released CDC, we used it heavily for a system we built. Yet, not all competitive DB systems had a direct analog to it at the time. More common examples are some of the stored procedure functions available in SQLServer that weren't in other systems that we used regularly. Any of those could have made a DB porting job a pain in the ass. Overall though, almost every system I have ever had input on or control over architecture we have hidden the database behind either an API or data layer of some sort that made the application ignorant to how data was stored, accessed and where it was located. The idea behind this isn't that I think switching databases is a normal thing, but more so we could change data location, structure etc all without affecting application design. I've been doing that since the early 90's, it was something I was just ingrained with because when I started writing code all our data was stored in flat files and so our code was the database, so isolation was critical to not affect consumers.