Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Why don't Windows/Linux use relational databases (RDBMS)?
I know they use file systems to store all data but don't you think it is more efficient to use databases like we use in web sites/web apps?
Please elaborate on the use of a file system over a database for storage.
This is not a duplicate of When should use of database be preferred over parsing data from a text file? I am talking in terms of only operating system contexts, and that question is generalized.
Today, most database management systems (e.g. PostGreSQL, MongoDB, etc...) internally keep their data inside OS files (in the past, some DBMSs used raw disk partitions directly).
On recent computers still using spinning hard disks, the disk is so slow - relative to the CPU or the RAM - that adding a few software layers is not relevant. SSD technology might change that a bit, and some file systems are optimized for SSDs.
Files are present in most OSes in general for historical and social reasons (in particular, C compilers and most tools - editors, linkers - want files, so there is a chicken and egg issue), and because there are a lot of very good file system implementations.
BTW, some essential system facilities can use databases. For example on Linux PAM can be configured to use information in databases (but this is rarely done in practice). Also, some mail servers may store some or most of their data in databases (e.g. Exim).
Files are slightly lower abstractions than databases, so they can be easier to implement (as the file systems & VFS layer in the Linux kernel) and faster to use. In particular, the operations on files are much more restricted than those on databases. In fact, you could see files or file systems as some very restricted databases!
You could design an operating system without any files, but with some other orthogonal persistence machinery (e.g. having every process be persistent, then you don't care much explicitly about storage, since the OS is managing persistent resources). This has been done in several academic operating systems(1) (and also in the Smalltalk and Lisp machines of the 1980s, somehow in the IBM System i, a.k.a. AS/400, and in some toy projects linked from osdev), but when you design your OS this way you cannot leverage on many existing tools (e.g. you also need to make your compiler and your user interface from scratch, and that is a lot of work).
Notice that microkernel operating systems might not need files provided by kernel layers since the file systems are just application servers (e.g. Hurd translators running in userland). Look also at the unikernel approach in today's MirageOS
Linux (and probably Windows, which got most of its inspiration from VMS & Unix) need files to work. At the very least, the init program (the first program started by the kernel) must be an executable stored in a file (often /sbin/init, but it could be systemd these days), and (nearly) all other programs are started with execve(2) syscall so must be stored in a file. However, FUSE enables you to give file-like semantics to non-file things.
Notice also that on Linux (and perhaps even Windows, which I don't know and never used) sqlite is a library managing some SQL database in a files and providing an API for that. It is widely known that Android (a Linux variant) uses a lot of sqlite files (but it still does have a POSIX-like file system).
Read also about application checkpointing (which, on many current OSes, is implemented to write the process state in files). Pushed to the extreme, that approach does not need to manually write application files (but only to persist the entire process state using the checkpointing machinery).
Actually, the interesting question is why do current operating systems still use files, and the answer is legacy, and economic and cultural reasons (sadly, most programming languages and libraries today still want files).
Note 1: persistent academic OSes include Lisaac & Grasshopper, but these academic projects seem to be inactive. Look also into http://tunes.org/ ; it is inactive, but has gotten lots of discussions around such topics.
Note 2: the notion of file has widely changed over time (look at this answer about my first programming experiences): the first MSDOS on 1980s IBM PCs (no directories!), the VMS -on 1978 Vaxen- (had both fixed-record files and sequential files, with a primitive versioning system), the 1970s mainframes (IBM/370 with OS/VS2 MVS) had a very different notion of files and file systems (in particular because at their time the ratio of hard disk access time to core memory access time was a few thousand - so at that time disk ran relatively faster than today, even if today's disks are absolutely faster than in the previous century, today the CPU / disk speed ratio is about a million; but we now have SSDs). Also, files are less (or even not) useful when the memory is persistent (as on CAB500 magnetic drum, 1960s; or future computers using MRAM)
Although this is opinion-based, I think it's just another historical artifact. Early OSes used a simple file system design for performance that was reasonably strongly tied to the characteristics of the hardware available at the time, and it's been the same way ever since. It's difficult to change the old file read/write APIs for more transactional query/insert APIs once they were established.
All current file systems have a requirement to be backward compatible with these old APIs.
Microsoft did think about replacing the file system with an RDBMS-based one, in the Longhorn development. That was too much of a change for them to pull off, but you do see their efforts continue in the form of Windows Search (where an RDBMS is used to store a copy of metadata) and features such as SQL Server's Filestream system (where a database table of file data is exposed to the OS as an ordinary directory allowing both Windows Explorer access to the data, and SQL queries of the same data).
Other OSs do have RDBMS filesystems. AS/400s used to have these, though I never learned enough about them; I remember how weird it appeared at the time). I think other mainframe systems have the same kind of approach.
The real reason is a lack of need for it. Layering databases on top of files, rather than merging them, handles the vast majority of situations at least as well as a merged solution with substantially reduced complexity. In some situations others have mentioned, we've also layered parts of files on top of databases (such as permissions structures). In that case, the database managing those permissions is remarkably simpler than a commercial RDBMS.
There are advantages to merging them, but so far those have been few and far enough between that the movement is growing slowly. Consider how rare it is for people to say "Give me the 3rd column of every invoice I've received since 2010, and sum them together," or "don't let me delete this file until I've removed it from the Excel spreadsheet also."
File systems have a few advantages over relational databases that keep them going:
sync mode.) +1 for all your other points, esp. fast heirarchical performance where a ton of stuff in one subdir doesn't slow down performance in another subdir. Unless each dir or file is a different table...
Jun 3, 2015 at 19:16
I think the other answers provide a wide spectrum of reasons as to why operating systems do not rely on relational databases internally/exclusively so I'll just share an interesting piece of information that I once stumbled upon.
Apparently, there are technologies that allow you to mount relational databases as file systems when their use is justified. Oracle DBFS (Database File System) is an example. This snippet from the documentation explains the rationale behind it quite well:
Database File System (DBFS) leverages the features of the database to store files, and the strengths of the database in efficiently managing relational data, to implement a standard file system interface for files stored in the database. With this interface, storing files in the database is no longer limited to programs specifically written to use
BLOBandCLOBprogrammatic interfaces. Files in the database can now be transparently accessed using any operating system (OS) program that acts on files.
The solution provides a set of interfaces (command line clients, code libraries) for LOB data that is stored in database tables. This can be used on Windows and Linux operating systems (although as far as I can tell, the level of integration varies between them)
Source: docs.oracle.com
According to the documentation, the file system should be possible to use in a transparent manner on Linux
On Linux, the
dbfs_clientalso has a mount interface that utilizes the Filesystem in User Space (FUSE) kernel module to implement a file-system mount point that provides transparent access to the files stored in the database and requires no changes to the Linux kernel. It receives standard file system calls from theFUSEkernel module, and translates them into OCI calls to the PL/SQL procedures in the DBFS Content Store.
Therefore, the answer to your question is that, in general, there's no reason for an operating system to use a relational database as a file system (and in case of the core components of an OS, this would actually be troublesome). At the same time it is possible for one to do it when some problem calls for it.
The main function of any OS is to facilitate interactions between applications, hardware and the users.
So.. why don't Windows/Linux OS use relational Databases (RDBMS)? This is a question of biblical proportions, but the short answer is: There is not any real benefit to be gained from using a complex structure such as an rdbms as a file system.
"Relational" is the operative word in "Relational Database" and most data stored in a file system is unrelated to other data. File systems generally are implemented as limited databases, just not relational ones.
