SQL Fundamentals

What SQL is

SQL (Structured Query Language) is the language you use to define, query, and change data stored in a relational database. "Relational" means the data lives in tables — rows and columns — and tables relate to each other through shared key values instead of nested structures. You write what result you want; the database figures out how to get it. That's what makes SQL declarative: a SELECT statement describes the shape of the answer, not the steps to produce it.

SQL was built for exactly this job in the early 1970s at IBM, based on Edgar F. Codd's relational model, and it has stayed the dominant way to work with structured data ever since. Nearly every relational database — PostgreSQL, MySQL, SQL Server, Oracle, SQLite — speaks a dialect of it.

Why it exists

Before relational databases, applications navigated data by following explicit pointers between records — you had to know the physical path to the data you wanted. Codd's relational model replaced that with a simpler idea: store data as tables of rows, and let a query language locate rows by their values instead of their position. SQL is that query language. It freed application code from knowing how data was physically stored, and it gave every relational database a shared vocabulary for asking questions of data: which rows, which columns, in what order, combined with what other data.

What SQL is made of

SQL splits into sublanguages that each do a different job:

• DDL (Data Definition Language) — CREATE, ALTER, DROP. Defines the shape of the data: tables, columns, constraints.
• DML (Data Manipulation Language) — INSERT, UPDATE, DELETE. Changes the rows inside that shape.
• DQL (Data Query Language) — SELECT. Reads rows back out. In practice most people lump this in with DML, but it's worth naming separately because it's the statement you'll write most.
• DCL (Data Control Language) — GRANT, REVOKE. Controls who can do any of the above.
• TCL (Transaction Control Language) — BEGIN, COMMIT, ROLLBACK. Groups statements so they succeed or fail together.

Every SQL task you do falls into one of these five buckets. Once you can place a statement in its bucket, the syntax around it gets much easier to predict.

Purposes and use cases

SQL shows up anywhere structured data needs to be stored, queried, or changed reliably:

• Application backends — user accounts, orders, inventory: anything an app needs to persist and look up.
• Reporting and analytics — aggregating rows into totals, averages, and trends with GROUP BY and aggregate functions.
• Data engineering pipelines — moving and reshaping data between systems, often expressed as SQL transformations.
• Administration — creating schemas, managing permissions, tuning how data is stored and indexed.

If a job involves asking "give me the rows where..." or "how many of these match that...", it's a SQL job.

Where SQL fits in its ecosystem

SQL is the interface, not the database. Every relational database implements the standard (ISO/IEC 9075, maintained jointly with ANSI) to different degrees, and each adds its own extensions — PostgreSQL's JSONB type, MySQL's AUTO_INCREMENT, SQL Server's TOP. Learning SQL fundamentals means learning the common core that transfers across all of them: SELECT, joins, WHERE, GROUP BY, constraints, transactions. Vendor-specific courses build on top of that core with each product's own syntax and tooling.

SQL also sits next to, not instead of, NoSQL systems (document, key-value, graph, and columnar stores) that trade the relational model for other strengths, usually around horizontal scale or flexible schemas. Knowing SQL well makes it much easier to evaluate when one of those alternatives is actually the better fit.

Limits

SQL is not a general-purpose programming language. It has no first-class concept of loops or complex control flow in standard form, though most databases bolt on procedural extensions (PL/pgSQL, T-SQL) for that. It also allows things pure relational theory would forbid, like duplicate rows and ordered results, and its NULL handling uses three-valued logic (true, false, unknown) that trips up even experienced users. Despite the existence of a formal standard, no database implements it completely, and everyday details — string concatenation, date arithmetic, auto-incrementing keys — vary enough between vendors that "standard SQL" code often needs small edits to run somewhere else.

When it's the right choice

Reach for SQL and a relational database when your data has a clear structure, when relationships between entities matter (orders belong to customers, line items belong to orders), and when you need strong consistency guarantees — a transaction either fully happens or it doesn't. It's a weaker fit when the schema is genuinely unpredictable ahead of time, when you need to scale writes horizontally across many machines more than you need strict consistency, or when the data is naturally a graph or a blob rather than rows and columns. Most systems end up using SQL for the core structured data and something else alongside it for the parts that don't fit that shape.