The SQL lesson before this one was portable — it would run almost unchanged on MySQL or SQLite. This one is deliberately not: jsonb, arrays, window functions, upserts, and row-level security — the features that make Postgres the default across every project in this portfolio.
Theory 1 of 3
SQL is a spec. Postgres is an opinion.
"SQL" names a standard, not a product — SELECT/WHERE/JOIN/GROUP BY from the last lesson are the portable core every relational database implements roughly the same way. Everything in this lesson is Postgres going further than the spec strictly requires: real JSON types, arrays as a native column type, window functions, single-statement upserts, and a security model enforced inside the database itself. None of it is exotic — it's why Postgres, not "SQL" in the abstract, is the actual choice behind almost every schema in this portfolio.
Theory 2 of 3
jsonb and arrays are real types, not text with extra steps.
The last lesson's closing tradeoff — a jsonb column instead of a child table — undersold what you get for paying that cost. Postgres doesn't just store the JSON as a string; it parses it into a binary format, validates it's actually valid JSON on the way in, and gives you real operators to reach inside it (->, ->>, @>) instead of deserializing a blob in application code just to check one field. Arrays get the same treatment — a native text[] column, not a comma-joined string you split by hand.
Theory 3 of 3
Row-Level Security: the boundary the database enforces, not the app remembers.
The classic multi-tenant SaaS bug is one code path that forgets WHERE tenant_id = ? — and now one customer can see another's rows. Row-Level Security moves that check out of application code and into a policy attached to the table itself, applied automatically to every query regardless of what it asks for. This isn't hypothetical for this portfolio: FireScout — the multi-tenant SaaS running elsewhere in this same stack — runs exactly this pattern in production. A query with a missing or wrong WHERE clause still can't leak another tenant's rows, because the database itself won't hand them over.
Done
Now you can tell when a schema is actually protecting you.
A jsonb column nobody indexes and nobody queries into is just a slower text field. A tenant filter that lives only in application code is one missed WHERE clause away from a breach. The difference between a schema an agent hands you that looks fine and one that's actually fine is exactly the stuff in this lesson — indexes, operators, and policies the database enforces whether or not the query in front of you remembered to ask.