An operating system is usually optimized to perform well for a large variety of workloads. Databases have a very specific workload and there are some possible (performance) optimizations if you, for example, bypass the operating system file caching and prefetching facilities and roll your own. Or if you control the scheduling of your operations. Take this with a grain of salt, it has been some time since I read about SQL Server internals, but this is what I remember.

If you think about what a DBMS does, you'll find the list looks a lot like an OS: I/O, memory management, task scheduling, resource arbitration. And the DBMS makes guarantees the OS does not, not least of which is transactions. To the extent the OS could supply the functionality needed by the DBMS, it must do so in a general way. The DBMS can implement specialized logic that increases both efficiency and certainty.

A textbook example is a file buffer. The OS provides write(2) or similar. It affords the abstraction of a linear sequence of bytes. The caller can write 1 byte or many, and the OS will take care of allocating/locating the block(s) and updating them. And write(2) doesn't even write! If you want to change the bits on the platter, you need fsync (and some faith in the hardware).

A DBMS by contrast is typically organized around pages, the size of which is a function of the disk blocks. Some of those pages maintain critical state information and are sync'ed to the disk frequently. The DBMS must also guard against data loss because of (say) power failure. It may choose to keep two copies of such data -- Jim Gray's so-called "ping-pong" algorithm -- so that even if the last one is corrupted due to insufficient voltage, the prior one will be OK. The DBMS's view of the disk is one of blocks, not bytes, that are strategically situated to minimize time lost waiting for it to spin or seek. The metaphor for writing data is less one of a stream and more like whack-a-mole: pop, pop, pop, done!

The astute reader will note Posix offers no services in support of splatting strategically situated blocks on the disk. I never read the code, but that would explain why Sybase in 1986 and 2016 lets the user define the database outside the filesystem.

Regarding Microsoft's Linux offering, we're coming full circle. The code Microsoft licensed from Sybase included an OS isolation layer in which Sybase implemented all those OS-like services. To VMS, for example, Sybase was just 1 process, and Sybase itself managed the multiple connections and tasks. Microsoft incrementally, version by version, stripped that away and insinuated the DBMS into the OS. Doubtless there is kernel support in Windows specifically for SQL Server.

Later, mirabile dictu, we're told SQL Server has "its own OS". I suspect that layer was created as much for organizational reasons as technical ones. It lets the two groups define an API for use by the DBMS. The DBMS group gains some control, and the OS group isn't at their beck and call. But it turns out to be useful beyond that. I have to imagine one reason "SQL Server on Linux" is still a year away is that adapting that OS-interface layer to Linux is a nontrivial effort.