I think this is the paper https://www.cs.bu.edu/~jappavoo/Resources/Papers/unikernel-hotos19.pdf https://www.cs.bu.edu/~jappavoo/Resources/Papers/unikernel-h...

I think this is the paper https://www.cs.bu.edu/~jappavoo/Resources/Papers/unikernel-hotos19.pdf https://www.cs.bu.edu/~jappavoo/Resources/Papers/unikernel-h.... There's a great summary by cormacrelf below of some of the details. This kind of things comes and goes across the decades. Back in the 90s it was common for databases to implement their own file systems or memory management, but gradually the OSs of the day added features make this unnecessary. As we found then, you lose so much flexibility to modify the os via config changes, adding new monitoring or whatever if you had the db directly connected to the os. I'd hate to give that up for more efficiency. There's a lot of 'strength' in an OS separating various things from the database itself, giving that flexibility. A modern DB needs efficient interaction with the OS of course, but I'd say based on experience at many companies a bigger challenge than raw efficiency is the ability to implement changes in the db itself. I've worked on 4 or 5 major databases and we can always identify many ways to improve execution, plan selection, various aspects of the db, it's just the giant challenge to alter a big code base that blocks improvements more than OS layers. Improving plan choice can make queries thousands of times faster - but you have to be able to implement it.