When I was first introduced to Oracle years ago, I was surprised at how much it acted like an operating system inside. Once connected to the shell you could find processes running, examine memory through data dictionary queries and so forth. Tuning it involved looking at disk I/O patterns, memory usage and making your loops tighter. In the SQL world that meant indexing & reviewing plans for joins carefully.
MySQL & Postgres carry some of those same attributes. Even though they are user processes and the OS controls the lower levels, you would typically deploy them on their own servers, and give them all the memory & disk I/O you could, because they were their own operating systems essentially.
It's not clear to me how building a database "like an operating system" is something new. What I did see new in there was a consistency checking tool. That is super important. Because in a distributed environment you're bound to have drift.
Also I'd like to see how they managed to get full ACID Compliance. Fast network interfaces are great but there is still some latency which means hiccups when multiple nodes try to update the same row.
I agree with you that it's not an original analogy, in fact I think you can safely say that most larger, performance-oriented systems end up looking more like an OS than not. There's a large overlap in the problems that need to be solved and the resources available to distributed systems, that I'd be more skeptical of an implementation that didn't lean heavily on the OS, or at least borrow the general patterns.
To answer your question about consistency, we have implemented a transaction resolution mechanism inspired by Calvin. The whitepaper contains a lot more detail, but the short answer is that we use a consistent, distributed transaction log to provide a global order of all read-write transactions, which are executed deterministically on the responsible data partitions. This allows FaunaDB to provide a guarantee of strict-serializability for read-write transactions. Read-only transactions are by default a bit more relaxed and provide a hard guarantee of serializability in order to avoid global coordination overhead.
The key difference with conventional RDBMS systems is that transactions are deterministic. When interacting with a traditional RDBMS a client opens a transaction with BEGIN statement, then does reads and writes interactively at its own pace. In contrast, in Calvin-inspired systems clients send their transactions as one unit written in a severely restricted query language (disclaimer - not a FaunaDB engineer).
Yes, big databases can disable the OS scheduler (CPU pinning) and file caching (O_DIRECT) so they can perform workload-aware optimizations for better performance than general-purpose OS mechanisms.
MySQL & Postgres carry some of those same attributes. Even though they are user processes and the OS controls the lower levels, you would typically deploy them on their own servers, and give them all the memory & disk I/O you could, because they were their own operating systems essentially.
It's not clear to me how building a database "like an operating system" is something new. What I did see new in there was a consistency checking tool. That is super important. Because in a distributed environment you're bound to have drift.
Also I'd like to see how they managed to get full ACID Compliance. Fast network interfaces are great but there is still some latency which means hiccups when multiple nodes try to update the same row.