SQL

SQL is a language, not a database. The same language works across PostgreSQL, MySQL, Microsoft SQL Server, Oracle, and SQLite, with small dialect differences between them. It was created at IBM in the 1970s based on Edgar Codd's relational model and became an ANSI standard in 1986.

Data in a SQL database is organized into tables. A table for users might have columns like id, email, and created_at, and each row is one user. Relationships between tables are expressed with keys: a primary key uniquely identifies a row, and a foreign key in one table points at the primary key of another. An orders table holding a user_id foreign key is how you connect an order back to the customer who placed it.

SQL is declarative. You say what you want, not how to get it. When you write SELECT name FROM users WHERE country = 'India', you never specify whether to scan the whole table or use an index. The query planner inside the database decides that for you based on statistics and available indexes.

When you send a query, the engine parses it, checks that the tables and columns exist, and hands it to the query planner. The planner generates several possible execution plans, estimates the cost of each using stored statistics about table sizes and value distributions, and picks the cheapest one. You can see this plan yourself by prefixing a query with EXPLAIN.

The biggest performance lever is the index. Without one, finding rows where email = 'a@b.com' means reading every row in the table, a full table scan. With a B-tree index on the email column, the engine walks a sorted tree structure and finds the match in roughly log(n) steps. On a table with 10 million rows that is the difference between reading 10 million rows and reading around 24.

Joins are how SQL combines rows from multiple tables. A query that pulls each order along with its customer name joins the orders and users tables on user_id. Internally the engine may use a nested loop, a hash join, or a merge join depending on table sizes and indexes. Most SQL databases also wrap groups of statements in transactions that give ACID guarantees, so a money transfer that debits one account and credits another either fully commits or fully rolls back.

Reach for SQL when your data has a clear structure, relationships matter, and correctness is non-negotiable. Banking ledgers, e-commerce orders, inventory, and user accounts are the classic fit because transactions and constraints stop the data from drifting into invalid states. A UNIQUE constraint on email guarantees you never get two accounts on the same address, enforced by the database itself rather than hoped for in application code.

The trade-off is schema rigidity and horizontal scaling. You define columns and types up front, and changing them on a huge live table can be slow. Relational databases also scale up (bigger machine) more easily than they scale out (many machines), which is why high-write workloads sometimes move to NoSQL stores. That said, modern Postgres comfortably handles tens of thousands of transactions per second on a single node, so most applications never hit that wall.

A common mistake is fearing joins. Joins are what relational databases are built and optimized for. Avoiding them by duplicating data across tables usually creates more bugs than it prevents, because now the same fact lives in two places and can disagree.