Perhaps, but commercial databases tend to guarantee some kind of data integrity, which is impossible unless they persist the contents of a transaction. I don't think they would use write caching by default, as it is fundamentally dangerous to this objective.
I don't think a well designed DB would do extensive read caching either. It's something that is more readily done by a kernel. As everyone has been saying, that's read caching is what most FS do for you (including NTFS) for free.
A DB can provide detailed information about their file I/O requirements through an mmap call anyway.
Indeed, transactional databases require non cached writes (and it's not only about filesystem caching but also about hardware caching).
As for read caching: of course they cache reads, it would be insane not to do it. The filesystem has no magic orb to tell it what exactly to cache, read ahead, discard from cache etc.