SQL

In short: “Structured Query Language” — the standard language for querying, changing and structuring relational databases (SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, etc.).

In more detail: SQL is an open standard implemented by almost all relational database systems (MySQL, PostgreSQL, MariaDB, SQL Server) — with small, vendor-specific deviations in the details (“SQL dialects”). Basic principle: data sits in tables with fixed columns, relationships between tables are represented via foreign keys.

In Depth

SELECT customers.name, SUM(orders.amount) AS total_revenue
FROM customers
JOIN orders ON orders.customer_id = customers.id
WHERE orders.date > '2026-01-01'
GROUP BY customers.name
ORDER BY total_revenue DESC;

SQL is divided into several sub-languages with their own tasks: DDL (Data Definition Language, CREATE TABLE/ALTER TABLE — defines the structure), DML (Data Manipulation Language, INSERT/UPDATE/DELETE/SELECT — changes and reads data), and DCL (Data Control Language, GRANT/REVOKE — governs access rights). The JOIN in the example shows SQL’s basic relational principle: instead of redundantly repeating customer data in every order, tables are linked via a foreign key (customer_id) and merged at query time when needed.

As a declarative language, SQL describes WHAT should be queried, not HOW — the concrete execution strategy (which index is used, in what order tables are joined) is handled by the database’s own “query planner”, based on statistics about the existing data. This separation lets database systems optimise queries independently of the written SQL text.

History and standardisation

SQL was developed at IBM in the early 1970s, based on Edgar F. Codd’s theoretical model of relational databases (1970). Since 1986, SQL has been an official ANSI/ISO standard, regularly developed further (SQL-92, SQL:1999, SQL:2003 with XML support, up to current versions with JSON functions). Despite standardisation, every database system doesn’t implement the standard 100% identically — PostgreSQL, MySQL and SQL Server differ in details (e.g. string concatenation: || in PostgreSQL, CONCAT() in MySQL), which is why “SQL compatibility” when switching databases is rarely completely frictionless.

SQL injection as a classic security risk

Because SQL queries were historically often built by simply concatenating strings, SQL injection (see SQLi) emerged as one of the best-known web security vulnerabilities: if user input is inserted directly into an SQL query unchecked, an attacker can manipulate the query structure itself through cleverly crafted input. Modern database libraries and ORMs prevent this with “prepared statements” (parameterised queries), where user input is strictly treated as a data value and can never be interpreted as part of the SQL syntax.

Transactions and ACID

A central SQL concept is transactions — several database operations are treated as an inseparable unit (either all succeed or none do), guaranteed by the ACID properties (Atomicity, Consistency, Isolation, Durability):

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

If the second UPDATE statement fails (e.g. due to a system crash), the database automatically undoes the first one too (“rollback”) — without transactions, money could “disappear” in the event of an error, because only the first booking was executed.

See also: MariaDB, PostgreSQL, MySQL, SQLi