SQL or NoSQL?

Someone on the Gatepass team reads that a famous company moved to a NoSQL database and "scaled to millions". Should you? The honest answer is "probably not yet", but to say why, you need to know what each kind of database is actually good at.

What a relational database gives you

Relational (SQL) databases, like PostgreSQL and MySQL, store data in tables with a fixed set of columns, and let you ask almost any question of it with SQL. Their strengths are exactly what Gatepass needed in the last lesson:

• Joins. Event plus venue plus tickets in one query.
• Transactions. Decrement the count and insert the ticket, all or nothing. The usual name for this bundle of guarantees is ACID: atomic, consistent, isolated, durable.
• Constraints. Unique, foreign key and check rules enforced on every write.
• Flexible querying. Questions you didn't plan for (sales by city by hour) are one new query, not a new data model.

The cost: one SQL database usually runs on one primary machine for writes. You can go a long way with a big machine and read copies, but spreading writes across many machines is hard and needs careful design.

What "NoSQL" actually means

"NoSQL" isn't one thing. It's a family of databases that each give up some relational features to be very good at something specific. The main kinds:

• Key-value stores are giant dictionaries: give a key, get a value. Ridiculously fast, but you can only look things up by key. Perfect for sessions and caches.
• Document stores keep each record as a JSON-like document. Good when records vary in shape and are usually read whole, like a product with dozens of optional attributes.
• Wide-column stores are built for enormous write volumes spread over many machines: sensor readings, activity logs, messages.
• Graph databases make "friends of friends who like this band" fast, where SQL would need many joins.

What most of them share: they partition data across many machines from the start, so they can grow writes and storage almost without limit. To make that work, they give up joins, cross-record transactions or flexible queries, or all three.

The real tradeoff: query flexibility vs scale

With SQL you design tables around the data, then write whatever queries you need. With most NoSQL stores you design around the queries: decide every access pattern up front, and shape the data so each one is a single fast lookup.

Take "my tickets" in a key-value store like DynamoDB. You'd store tickets under a key like user#7, so one read returns them all. Fast and scalable. Now the organiser asks for "all tickets for event 42". The data isn't keyed that way, so you either scan everything or store every ticket a second time under event#42, and keep both copies in sync yourself.

Choosing for Gatepass

Run through the Gatepass requirements:

• Bookings must never oversell, and a ticket must exist exactly when the payment does. That's transactions, a SQL strength.
• Data is relational: venues, events, tickets, users, all pointing at each other.
• The organisers keep asking new questions. Flexible querying is valuable.
• Scale is modest: even across forty cities, a few hundred writes a second at peak, well within one good SQL primary.

So Gatepass stays on PostgreSQL. That's the answer for most products, most of the time: start relational, and reach for a specialised store when a specific workload outgrows it.

When NoSQL is the right call

There are real cases where a NoSQL store is the better primary database:

• Write volume beyond one machine. Millions of writes a second, like chat messages or IoT readings, where partitioning is needed from day one.
• Simple access by key at huge scale. Shopping carts, sessions, user preferences: always read and written by one id.
• Truly variable record shapes. A catalogue where every product type has different attributes, read whole by id.
• Global, always-writable data where you'd rather accept conflicts than reject writes during a network split.

Note what's not on the list: "it's more modern", "it's schemaless so it's faster to build", "it scales better" with no numbers. A schemaless database still has a schema; it just lives in your application code, unenforced, where every bug can write a slightly different shape.

Check yourself

Which Gatepass feature is the strongest candidate for a key-value store beside Postgres?

ABookings, because they're the most important dataBVenues, because there are few of themCLogin sessions, looked up by session id on every requestDSales reports, because organisers run them often

Key takeaways

• Relational databases offer joins, transactions, constraints and flexible queries; scaling writes across machines is their hard part.
• NoSQL is a family (key-value, document, wide-column, graph), each trading general querying for one access pattern at scale.
• With NoSQL you design around queries up front; new questions often mean storing data again in a new shape.
• Default to a relational database; add specialised stores for specific workloads beside it.
• Choose NoSQL as the primary store for a reason with numbers: write volume, key-only access, or global writes.