I'm trying to understand the distinction between a database, a database management system, and a storage format. Many explanations describe a database as an organized way to store, retrieve, and modify data safely and efficiently, often with guarantees such as ACID transactions.
If that's the case, could a CSV file be considered a database if software were built around it to support querying, updates, indexing, locking, and transactional behavior? Some explanations say CSV files do not count because they only store raw data, but that makes me wonder whether the database is defined by the file format or by the software and guarantees built around it.
I'm currently using SQLite through Python and come from an embedded-systems background, so I'd like to understand what parts of SQLite make it a database system rather than merely a file format. My current understanding is that the storage format is only one component; the management software and the capabilities it provides are what matter most.
3 Answers
It helps to separate a few concepts. CSV is a storage format, SQL is a query language, and ACID describes guarantees a system may provide. A database can simply mean an organized collection of data, while a database management system is the software that provides querying, updates, indexing, concurrency control, recovery, and other services.
So a CSV file by itself is usually called a data file or datastore. A program that uses CSV files while providing database-like operations could reasonably be called a database system, even if it would be inefficient. SQLite works this way conceptually: it stores data in a file, but its library manages transactions, locking, queries, indexes, and recovery around that file.
There is no single universally accepted minimum definition. Historically, database has meant an organized collection of information, and databases can be relational or non-relational. ACID and SQL are common features, not requirements: some databases use key-value access and eventual consistency instead.
In ordinary engineering conversations, “database” often implies an engine that provides structured access and handles details such as indexes, data types, concurrent operations, durability, and recovery. A CSV viewed in a spreadsheet or edited with shell commands is better described as a file or simple datastore, while CSV files accessed through a purpose-built query and transaction layer could reasonably be considered the storage for a database.
That matches what I was missing: the on-disk representation is only one part of the whole system, rather than the definition of the database by itself.
Yes, you can technically build a database on top of CSV files. You could add code for searching, inserting, updating, indexes, and even transactions. At that point, though, the database is the software layer plus the stored data, not the CSV format alone.
The reason people usually do not call a plain CSV a database is practical: rows are stored sequentially, so searching may require scanning the whole file, and small changes can require rewriting much of it. Multiple writers can also corrupt or overwrite one another without locking and recovery. CSV is still perfectly useful for imports, exports, configuration, and small datasets; it is simply a poor general-purpose database backend.
Efficiency and scalability are not necessarily part of the strict definition, but they explain why everyday technical usage usually reserves “database” for something with more management features.
That distinction cleared things up for me too. The file is just the persistence layer; SQLite is the system that gives the file database behavior.