i wanted this to be an entry point for the sql series, a clear “what is sql” reference you can scan quickly and return to later. even with constant technology shifts, relational databases and sql still anchor a huge part of modern software and analytics.
quick answer#
sql is the language most relational databases use to define, read, update, and manage data. it is declarative, which means i describe the result i want and the database engine decides how to execute it efficiently. this model has held up for decades because sql is expressive, portable, and understandable. vendor dialects differ, but the core grammar is still recognizable almost everywhere.
who this is for#
- people new to data and databases who want a quick introduction
- developers who use databases daily but never got the historical context
- analysts and engineers deciding when sql is the right tool
what sql is#
at its core, sql works on tables made of rows and columns. tables are connected by keys, and queries combine or reshape those tables to answer questions.
sql usually appears in four practical categories:
- querying data with
select,where,join,group by - modifying data with
insert,update,delete - defining structures with
create table,alter table,create view - controlling access and safety with
grant,revoke
the most important mindset shift is this: sql is set-based and declarative, not loop-first and imperative.
a short history of sql#
sql has been around for more than 50 years, and that long runway is one reason it feels “locked in” as a standard.
- 1970: edgar f. codd publishes the relational model at ibm
- mid 1970s: ibm researchers develop sequel, which later becomes sql
- 1979: oracle ships one of the first commercial sql database implementations
- 1986: ansi publishes the first sql standard (i personally ONLY write ansi standard for maximum portability)
- 1990s to 2000s: major vendors expand features and performance, while the core language stays recognizable
- today: sql powers operational databases, analytics warehouses, bi tools, and transformation frameworks
why sql is important#
sql is still important for practical reasons, not nostalgia.
- it is a common language shared by developers, analysts, and data engineers
- it is standard enough that skills transfer across many systems
- it lets database engines optimize queries with indexes and planners
- it models relationships clearly through keys and joins
- it supports transactional consistency for critical business data
for me, one of the biggest advantages is ease of learning. for common querying and reporting tasks, sql usually has a lower starting barrier than learning a full general-purpose programming language like python.
when and where to use sql#
sql fits especially well in these environments:
- application databases like postgresql, mysql, and sql server for transactional systems
- analytics platforms like snowflake, where large-scale reporting and transformation matter most, i cover that context more in the difference between snowflake and the “other” databases
- data transformation workflows where repeatable models and tests are required
- reporting and business intelligence when teams need consistent, auditable metrics
sql is usually not the best first tool for heavy imperative algorithms, event orchestration, or specialized graph traversal.
if you want a practical comparison between snowflake and operational database systems, i break that down in the difference between snowflake and the “other” databases.
key features worth knowing early#
- joins to combine related entities through keys
- aggregations (
sum,count,avg) to move from row-level detail to summaries - window functions for ranking, running totals, and partitioned calculations
- transactions for safe multi-step writes (
begin,commit,rollback) - constraints (primary keys, foreign keys, uniqueness) to enforce data quality
- views and ctes to make complex logic readable and reusable
a few simple examples#
filter rows#
SELECT
order_id,
order_date,
total_amount
FROM orders
WHERE order_date >= DATE '2026-01-01';join related data#
SELECT
c.customer_name,
o.order_id,
o.total_amount
FROM orders o
JOIN customers c ON c.customer_id = o.customer_id;aggregate to a useful metric#
SELECT
customer_id,
SUM(total_amount) AS total_spend
FROM orders
GROUP BY customer_id
ORDER BY total_spend DESC;use a transaction for safe updates#
BEGIN;
UPDATE accounts
SET balance = balance - 100
WHERE account_id = 1;
UPDATE accounts
SET balance = balance + 100
WHERE account_id = 2;
COMMIT;faq#
is sql the same thing as a database?#
no. sql is a language, and a database engine is the system that executes it. two engines can both support sql while differing in extensions, performance behavior, and tooling.
what is the fastest way to get good at sql?#
i suggest learning in this order: filtering, joins, aggregation, then window functions. if you can always explain the grain of one row in your result, your queries become much easier to trust.
when should i think twice about using sql?#
if your core problem is orchestration, low-latency event handling, or algorithm-heavy logic, sql alone is usually not enough. in those cases, use sql for data access and pair it with application or workflow code.
references#
- sql (wikipedia)
- sequel (programming language)
- iso/iec 9075 (sql standard)
- history of sql standards (wikipedia)
