SQL vs NoSQL: A Database Primer for Frontend-Focused Developers
The real decision is not which is faster — it is whether your data's relationships are known and stable, or genuinely variable. That decides the rest.
A frontend-focused developer moving into full-stack work usually meets this decision for the first time on a real project — and "SQL is more traditional, NoSQL is more modern" is exactly the wrong axis to decide it on.
What actually distinguishes them
A SQL (relational) database enforces a fixed schema up front — every row in a table has the same columns, and relationships between tables (a booking belongs to a customer, belongs to a vehicle) are explicit, enforced foreign keys, not something the application layer has to remember to maintain correctly on its own. A NoSQL (document) database like MongoDB stores flexible, self-contained JSON-like documents — no enforced schema, no built-in cross-document relationship enforcement.
The actual decision axis
Are the relationships between your data known, stable, and important to enforce (a booking MUST reference a real, existing vehicle — an orphaned booking is a real data-integrity bug, not just an inconvenience)? SQL is built for exactly that case, and its foreign-key constraints enforce it at the database level, not by trusting every piece of application code to check correctly every time. Is each record largely self-contained, with a shape that varies record to record and evolves quickly? That's NoSQL's actual strength.
The real-world example already on this site
The Amber Car Rental case study's database-level exclusion constraint (covered in its own post in the production-notes pillar) is a SQL-specific feature — Postgres enforcing "no two rows may overlap" directly at the database layer, impossible to accidentally bypass from application code. That's a concrete, real example of exactly the kind of enforced-relationship guarantee the previous section describes, not a hypothetical.
The honest, practical default
For most real applications — anything with clear entities and relationships between them (users, orders, bookings, invoices) — a relational database is the safer starting default, specifically because it catches data-integrity bugs at write time instead of silently allowing them and discovering the mess later. Reach for a document database when you have a specific, real reason: genuinely schema-flexible data, or a access pattern that's overwhelmingly "fetch one big self-contained document," not "my team heard NoSQL scales better."