Data formats that survived every trend

In computing, we love new things! I have to admit, sometimes it is a bit excessive ^^ From time to time, we get a new format promising to be simpler, faster, more compact, or more flexible than the previous ones. Yet, when we look at systems that have actually been running for decades, we often find the same survivors.

Some data formats have gone through several generations of programming languages, operating systems, and architectures without disappearing. They have seen mainframes, desktop applications, the web, the cloud, distributed systems...

Why are these formats still here while so many others have disappeared?

The immortal formats

CSV: The underrated veteran

CSV (*Comma-Separated Values*) seems almost too simple. No complex structure, no mandatory schema. And yet, it can be found everywhere: database exports, Excel files, analysis tools, etc.

Its strength is precisely its simplicity. A CSV file can be opened with a spreadsheet application, a text editor, and even practically any programming language.

I have often found myself using a simple CSV file to solve a problem in a few minutes, while a more "elegant" solution would have required much more work.

However, the format is actually a bit more complex than it looks. For example, if a value contains a comma, a line break, or quotation marks, it must be properly escaped. This is often where "home-made" implementations start producing files that cannot be correctly read anymore. A line containing quotation marks must double the internal quotation marks:

name,comment
Dupont,"He answered ""yes"" yesterday"

XML: Declared dead for 15 years

If there is one format that is regularly declared obsolete, it is XML. But it is still here!

It is often considered verbose:

<user>
    <name>Cyril</name>
    <email>cyril@example.com</email>
</user>

Compared to JSON, it can look heavy. Yet XML remains widely used in office documents (DOCX, XLSX, ODT), industrial data flows, SOAP, etc.

Its main advantage is that it does not only carry data: it can also carry structure, constraints, and rich metadata.

JSON: The current king of the Web

Created in the early 2000s, JSON is now more than 20 years old, but its massive adoption mainly dates back to 2005-2010.

Example:

{
  "name": "Cyril",
  "email": "cyril@example.com"
}

It has several qualities that explain its success: a compact syntax, easy readability, a good match with JavaScript objects, and native support in almost every programming language. Personally, I like using the JSON format.

But what is interesting is that JSON did not replace all other formats. It mainly found its place in application data exchanges.

SQL: The data language that has crossed decades

Created in the 1970s from IBM's work on the SEQUEL language (*System R*), SQL became an ANSI standard in 1986 and an ISO standard in 1987.

Unlike CSV, JSON, or XML, SQL is not really a data format: it is a language used to define, manipulate, and query data stored in relational databases.

However, SQL scripts and database dumps have been a very durable way of representing structured data for decades. An SQL file containing `CREATE TABLE`, `INSERT`, or `COPY` statements can often still be read and adapted long after it was created.

Example:

INSERT INTO users (id, name, email) VALUES (1, 'Cyril', 'cyril@example.com');

An SQL dump created 20 years ago can often still be understood today with only minor modifications. This longevity is remarkable in a field where frameworks change every three years.

YAML: The survivor of configuration files

Newer than the others, YAML has established itself in the configuration world: Docker Compose, Kubernetes, GitHub Actions, etc.

Example:

database:
  host: localhost
  port: 5432

Its readability is pleasant, although its indentation rules can sometimes become a source of frustration. I have already spent more time looking for a misplaced space in a YAML file than writing the configuration itself… But with generative AI, this is no longer really a problem these days.

Why do these formats survive?

Their common point is not that they are perfect. None of them are. They survive because they have several essential qualities.

Human readability

All these formats can be read with a simple text editor (well, assuming your file is not several GB in size...). When a system fails, being able to open a file and understand what it contains remains a huge advantage.

Simple tooling

They have huge ecosystems with parsers, validators, and above all libraries in almost every programming language. This availability greatly reduces adoption costs.

Long-term compatibility

A good data format must be readable long after it was created. This is often more important than raw performance. A company may prefer a slightly less efficient format that can still be understood in 10 years rather than an ultra-optimized format abandoned after two years.

Data formats that are now marginal

The history of computing is filled with formats that are now forgotten or have become difficult to use:

• SGML (Standard Generalized Markup Language): created in 1986, SGML strongly influenced HTML and XML. Widely used in some industrial and document-related fields, it was gradually replaced by XML, which was simpler and better suited to the Web;

• Proprietary EDI (Electronic Data Interchange) formats: many data exchange formats developed by companies or specific industries have disappeared or remain confined to historical systems;

• ASN.1 (Abstract Syntax Notation One) in some use cases: a data description format created in the 1980s, still used in certain fields such as telecommunications, but much less visible in everyday software development;

These formats show that a format can be technically solid and remain in use for decades, while gradually losing its place when a simpler, more open, or better-adapted format appears.

Conclusion

Technology trends move quickly, but the fundamental needs remain the same: storing, exchanging, configuring, and retrieving data. The formats that survive for decades are not necessarily the most elegant or the most efficient. They are above all the ones that managed to find a balance between simplicity, readability, compatibility, and stability.

In 20 years, new formats will probably have appeared. But I would bet that somewhere we will still find:

• a CSV file exported from an old system;
• an XML document used by an administration;
• a JSON API;
• a YAML deployment file;
• and of course… an SQL query that has been running for much longer than expected.

Time will tell!