Somewhere right now, a team is choosing MongoDB because "SQL doesn't scale", and another team is forcing a deeply nested, constantly changing document into twelve relational tables because "NoSQL is for hipsters". Both teams will spend the next year paying for a decision they made in an afternoon.

SQL versus NoSQL isn't a fashion choice. It's a question about the shape of your data and the questions you'll ask of it. Let's clear out the myths first, then talk about how to actually choose.

First, what we're comparing

Relational databases (MySQL, PostgreSQL, SQL Server) store data in tables with a fixed schema, connect them with keys, and let you ask almost any question with SQL. They give you transactions, constraints and joins as standard.

"NoSQL" is a loose label for several quite different things:

• Document stores (MongoDB, Firestore): JSON-like documents, flexible structure per record.
• Key-value stores (Redis, DynamoDB at its simplest): look up a value by its key, extremely fast.
• Wide-column stores (Cassandra): built for huge write volumes spread over many machines.
• Graph databases (Neo4j): relationships are the main thing you query.

"Should we use NoSQL?" is therefore a slightly broken question. Redis and Neo4j have almost nothing in common except what they're not.

Myth vs reality

Myth: "NoSQL is faster"

Reality: NoSQL databases are fast at the access patterns they were designed for. A key-value lookup in Redis is hard to beat. But ask a document store for something it wasn't modelled for, like a report joining three collections, and it gets slow or awkward quickly. A well-indexed relational query is very fast too. Speed comes from matching the database to the query, not from the category.

Myth: "SQL doesn't scale"

Reality: relational databases run some of the largest applications on the internet. They scale up (bigger machines), out for reads (replicas), and further with caching and partitioning. What's genuinely harder with SQL is spreading writes across many machines. If you need that, you'll know, and most applications never get near it.

Myth: "NoSQL means no schema"

Reality: it means the database doesn't enforce one. Your application still expects fields to exist and have certain types. The schema just moves into your code, and old documents with old shapes stay around forever. Flexible on day one often means defensive if statements by day three hundred.

Myth: "NoSQL can't do transactions"

Reality: out of date. MongoDB has supported multi-document ACID transactions since version 4.0. But transactions aren't the default way you work there, and modelling is meant to keep related data in one document so you rarely need them. In a relational database, transactions are the everyday tool.

The real trade-off, in one table

The row that matters most for business software is "ask almost anything, even unplanned". Requirements change. Finance will ask for a report you didn't design for. In a relational database, that's a new query. In a store modelled around specific access patterns, it can be a data migration.

When NoSQL is genuinely the right call

• Caching, sessions, rate limits, queues: Redis, without much debate.
• Huge write volume with simple, known access patterns: events, sensor data, activity feeds, where you'll read by key and time.
• Truly variable records that you read and write as a whole and rarely query across, like per-user settings or content with very different fields per type.
• Serverless or real-time mobile setups where a managed document store (Firestore, DynamoDB) saves you running anything yourself.

Notice that most real systems end up with both: a relational database as the source of truth, plus Redis for speed. That's not indecision. That's using each tool for its job.

The middle ground: JSON columns in MySQL

Often what people want from NoSQL is "a few flexible fields". You don't need a second database for that. MySQL (5.7 and later) has a native JSON column type, and Laravel speaks it fluently:

Schema::table('units', function (Blueprint $table) {
    $table->json('features')->nullable();
});

// Query inside the JSON
Unit::where('features->furnished', true)
    ->whereJsonContains('features->amenities', 'parking')
    ->get();

Cast it with 'features' => 'array' on the model and you read and write it as a normal PHP array.

The catch: you can't index a JSON column directly. If you filter on one key a lot, expose it as a generated column and index that:

Schema::table('units', function (Blueprint $table) {
    $table->boolean('is_furnished')
        ->virtualAs("features->>'$.furnished' = 'true'");
    $table->index('is_furnished');
});

Now you have flexible attributes and fast filtering, inside the same transactional database as the rest of your data.

Three questions to decide

1. Do my records relate to each other, and do I need those relationships to stay correct? Contracts, tenants, invoices, payments: yes, very much. Relational.
2. Do I know every way I'll query this data? If not, relational keeps your options open.
3. Is my bottleneck write volume across many machines, or simple key lookups at huge scale? If yes, and you can measure it, that's where NoSQL earns its place.

What's your stack's split? Fully relational, fully document, or the very common "MySQL plus Redis" combination?