cheat sheets / databases
SQL, PostgreSQL & MongoDB Cheat Sheets
Quick references for the queries you write daily, plus the two things that explain most database problems: which JOIN you actually meant, and why the query got slow.
Whether you are on relational or document storage, the muscle memory takes a while, and a good reference saves real time until it sets in. The four below cover the databases you are most likely to touch. What a reference will not tell you is why a query that worked fine last month now takes thirty seconds, so the sections after them cover joins and indexes, which between them account for most database frustration.
01 · RELATIONAL
SQL & PostgreSQL
The query language every back-end and data role relies on. The Learn X in Y Minutes entry is the odd one out and worth knowing about: it teaches the fundamentals as a single commented file rather than acting as a lookup table.
- SQL / MySQL Cheat Sheet ↗SELECTs, JOINs, GROUP BY, and schema commands in a clean, scannable reference.quickref.me
- PostgreSQL Cheat Sheet ↗Postgres-specific syntax, psql meta-commands, and data types for the most-loved open-source database.devhints.io
- SQL in Y Minutes ↗All of SQL as one commented example file — the fastest way to learn or refresh the fundamentals.learnxinyminutes.com
02 · JOINS
The four joins, and the one people get wrong
An inner join returns rows that match on both sides. A left join returns every row from the left table, filling in nulls where the right side has no match. A right join does the mirror image, and a full outer join returns everything from both sides with nulls wherever a match is missing. That is the whole set, and most confusion comes from a single trap rather than from the definitions.
The trap is putting a condition on the right-hand table in the WHERE clause of a left join. Doing that filters out the very rows whose right-hand columns are null, which silently converts your left join into an inner join. If you want to restrict the right side while still keeping unmatched left rows, the condition belongs in the join's ON clause rather than in WHERE. This one detail accounts for a remarkable share of "why are rows missing from my report" questions.
03 · WHY IT GOT SLOW
Indexes, and the query plan that tells you the truth
An index is a separate structure that lets the database find rows without reading the whole table. Without one, a filtered query scans everything, which is fine at a thousand rows and disastrous at ten million. This is why a query that was instant during development crawls in production: the behavior did not change, the row count did.
Indexes are not free. Each one has to be updated on every insert, update, and delete, so indexing every column trades read speed for write speed and disk. The columns worth indexing are the ones you filter on, join on, and sort by.
Rather than guessing, ask the database. Every major system can show the plan it intends to use for a query, including whether it will use an index or scan the table and how many rows it expects at each step. Reading a plan is the difference between speculating about performance and knowing. A common surprise is discovering that an index exists but is not being used, which often means the query wraps the column in a function or compares it to a different data type, either of which can prevent the index from applying.
The N+1 problem
Fetching a list of records and then issuing one additional query per record is the most common performance bug in application code, and it usually comes from an ORM making it invisible. Each individual query looks fast, and there are a thousand of them. Fetching related data in a single query, or in one additional query rather than one per row, is the fix.
04 · NOSQL
MongoDB and when a document store fits
MongoDB stores documents rather than rows, which suits data that is naturally hierarchical and read as a unit. Nesting related information inside one document means retrieving it in one read with no join, and it lets different records hold different fields without a schema migration.
The trade is that the shape you choose is optimized for a particular access pattern. Data duplicated across documents has to be updated in multiple places, and questions the shape did not anticipate can become awkward in a way they would not be in a relational schema. The honest summary is that relational databases are the safer default for data with meaningful relationships and unknown future queries, while document stores earn their place when the access pattern is well understood and the data is genuinely document-shaped.
05 · FAQ
Frequently asked questions
Are these database cheat sheets free?
Yes. All four are free to read without an account, and the MongoDB reference is the official manual published by MongoDB itself.
What is the difference between an inner join and a left join?
An inner join returns only rows that match on both sides, while a left join returns every row from the left table and fills in nulls where the right side has no match. Putting a condition on the right table in the WHERE clause of a left join filters out those null rows and silently turns it back into an inner join.
Why is my SQL query suddenly slow?
Most often because it filters on a column with no index and the table has grown. Without an index the database scans every row, which is unnoticeable at small sizes and severe at large ones. Asking the database for its query plan will show whether it is scanning or using an index.
Should I index every column?
No. Every index must be updated on each insert, update, and delete, so indexing everything trades write performance and disk space for read speed. Index the columns you filter on, join on, and sort by.
Should I use SQL or MongoDB?
Relational databases are the safer default when data has meaningful relationships and future queries are unknown, because the schema supports questions you have not thought of yet. A document store fits when data is genuinely hierarchical, read as a unit, and the access pattern is well understood in advance.