What Is a DBMS?

What Is a DBMS?

DBMS stands for Database Management System.

The TV station’s editor

Say a TV station is making a program of past footage from what is in its archive.

Someone takes the director’s request, finds the clips, and hands them over. That is the editor.

In a relational database, the software in that role is the DBMS.

Director (person, app)
     |  asks    ^  hands over
     v          |
Editor (DBMS)
     |  looks   ^  takes out
     v          |
Archive (data)

The data stays in the archive. The DBMS is what moves when asked.

What the editor does

A DBMS stands between the data and the people or programs using it (Oracle, “What Is a Database?”).

• Takes out: asked for “only Sato’s entries for November,” it gathers the matches and hands them over.
• Puts away: it takes in new data and stores it in the set place.
• Corrects and deletes: it changes only the data it was asked to change.
• Looks after: it also handles performance monitoring, backup, and recovery (Oracle, “What Is a Database?”).

“Editing” might sound as if the original data gets rewritten.

Even after a highlight reel is made, the original footage in the archive stays as it was.

When it only prepares what to hand over, the original data does not change. Of course, it can really rewrite data too.

All an app has to do is ask the DBMS to do these things.

The language of requests: SQL

Requests to a DBMS are usually written in a language called SQL (PostgreSQL, “The SQL Language”).

Think of it as the instruction sheet a director hands over. The DBMS reads it and acts.

But the editor does exactly what the sheet says.

If a malicious command is slipped in through an app’s input field, secret data can be read. This is called SQL injection (OWASP, “SQL Injection”).

So input values are kept separate from commands, and the DBMS account gets only the permissions it needs (OWASP, “SQL Injection Prevention Cheat Sheet”).

It takes on anything, and that is exactly why it needs protecting.

Two ways an editor can work

Some editors work on staff at the station. Others live inside an app.

PostgreSQL is the first kind. It runs on a server, and other computers connect over a network (PostgreSQL, “Architectural Fundamentals”).

SQLite is the second kind. It has no separate server and reads and writes ordinary files directly (SQLite, “About SQLite”).

Server type (PostgreSQL, etc.)

PC 1 ---+
        +--> Server
PC 2 ---+    (DBMS + data)

Embedded type (SQLite)

App (with DBMS) --> One file

Server type for everyone, embedded type inside a single app. The use decides the kind of DBMS.

Takeaways

The DBMS.

Capable as it is, until now you could not really talk to it without knowing SQL.

And with a malicious command, secret data could be carried off easily, so in a way it was a bit of a klutz.

But from now on, AI will step in and translate, like in a conversation with someone from another country.

It will take measures so that malicious commands do not get through.

We need the DBMS to do even more.

And we need to get to know it well, too 🤔

Trivia

• SQL: The language for making requests to a DBMS.
• SQL injection: An attack that slips malicious commands in through an input field.
• PostgreSQL: A free DBMS for relational databases.
• MySQL: An open source DBMS designed for web applications.
• SQLite: A small DBMS built into apps.
• Server: A computer that works on requests from other computers.
• Open source: Software whose program code is public and that anyone can use.

History

The beginning: from factory production control

In the 1960s, Charles Bachman at General Electric (GE) built a system for controlling factory production.

From it came the Integrated Data Store (IDS), described as the first disk-based DBMS used in everyday production (Computer History Museum, “Charlie Bachman”).

Walls and turning points: from corporate products to something anyone can use

In 1970, Edgar Codd of IBM published the idea of holding data in tables (Codd, “A Relational Model of Data for Large Shared Data Banks”).

IBM shipped its DB2 product in 1983 (IBM, “The relational database”).

Around the same time, in 1986, development of POSTGRES began at the University of California, Berkeley (PostgreSQL, “A Brief History of PostgreSQL”).

After the research project ended, it was reworked in 1994 and released as open source. In 1996 it was named PostgreSQL (PostgreSQL, “A Brief History of PostgreSQL”).

Now you could hire an editor for free.

What is in development now

• In May 2025, AWS made Amazon Aurora DSQL generally available, a distributed database with no servers to manage (AWS, May 27, 2025).
• In October 2026, the first release candidate of PostgreSQL 19 came out (PostgreSQL, October 15, 2026).

What comes next

Instead of running a DBMS on your own server, leaving it to an outside service like Aurora DSQL is becoming more common.

The job of taking data out and putting it away stays the same, but where it runs and who manages it are changing.

How much will be left to outside services as the norm is still unknown.