When to Choose NoSQL over SQL: A Simple Use Case Primer

TL;DR When you need flexible schemas, massive horizontal scale, or to ingest high-velocity, unstructured data—think NoSQL. In this post, we’ll walk through a concrete example (IoT heartbeat data) to see why a document store can outperform a relational database. Knowledge Base Relational databases have powered applications for decades and remain highly capable of solving nearly every kind of problem. However, they come with drawbacks and considerable complexity for certain use cases. They store data in a single structure—table rows. They excel at: ACID transactions and data integrity. Reads and writes are Atomic, Consistent, Isolated, and Durable, keeping your data correct even in the event of failures. Joins across well-defined tables. When relational data must be merged, SQL efficiently combines results. Mature tooling and SQL querying. Decades of ecosystem support: robust GUIs, ORMs, migration tools, performance analyzers, and the standardized SQL language for complex queries. Modern workloads—IoT telemetry, user-generated content, session stores—often demand schema flexibility, elastic scaling, and the ingestion of semi-structured data. That’s where NoSQL (document stores) shine. The Use Case: IoT Heartbeat Monitoring Imagine you’re building a sensor network that captures athletes’ heartbeat readings: Each device sends a JSON payload every second: { "deviceId": "sensor-42", "timestamp": "2025-05-14T09:00:05Z", "heartRate": 78, "battery": 91 } Key considerations: Thousands of write requests per second. Occasional reads such as: What was the average heart rate for sensor 42? What is the current battery level? SQL Approach A relational schema might look like: CREATE TABLE readings ( id SERIAL PRIMARY KEY, device_id TEXT NOT NULL, timestamp TIMESTAMPTZ NOT NULL, heart_rate INTEGER, battery INTEGER, CHECK (heart_rate >= 0 AND heart_rate

May 14, 2025 - 17:36

When to Choose NoSQL over SQL: A Simple Use Case Primer

TL;DR
When you need flexible schemas, massive horizontal scale, or to ingest high-velocity, unstructured data—think NoSQL. In this post, we’ll walk through a concrete example (IoT heartbeat data) to see why a document store can outperform a relational database.

Knowledge Base

Relational databases have powered applications for decades and remain highly capable of solving nearly every kind of problem. However, they come with drawbacks and considerable complexity for certain use cases. They store data in a single structure—table rows.

They excel at:

ACID transactions and data integrity. Reads and writes are Atomic, Consistent, Isolated, and Durable, keeping your data correct even in the event of failures.
Joins across well-defined tables. When relational data must be merged, SQL efficiently combines results.
Mature tooling and SQL querying. Decades of ecosystem support: robust GUIs, ORMs, migration tools, performance analyzers, and the standardized SQL language for complex queries.

Modern workloads—IoT telemetry, user-generated content, session stores—often demand schema flexibility, elastic scaling, and the ingestion of semi-structured data. That’s where NoSQL (document stores) shine.

The Use Case: IoT Heartbeat Monitoring

Imagine you’re building a sensor network that captures athletes’ heartbeat readings:

Each device sends a JSON payload every second:

  {
    "deviceId": "sensor-42",
    "timestamp": "2025-05-14T09:00:05Z",
    "heartRate": 78,
    "battery": 91
  }

Key considerations:

Thousands of write requests per second.
Occasional reads such as:

What was the average heart rate for sensor 42?
What is the current battery level?

SQL Approach

A relational schema might look like:

CREATE TABLE readings (
  id SERIAL PRIMARY KEY,
  device_id TEXT NOT NULL,
  timestamp TIMESTAMPTZ NOT NULL,
  heart_rate INTEGER,
  battery INTEGER,
  CHECK (heart_rate >= 0 AND heart_rate <= 220),
  CHECK (battery BETWEEN 0 AND 100)
);

Benefits

Robust schema validation ensures data always follows the same pattern.
Transactions provide ACID guarantees for correctness.

Drawbacks

Adding new fields (e.g., temperature) requires altering the schema, leading to potentially extensive migrations.
Horizontal sharding is complex due to the heavy write workload.
Inserts can become a bottleneck under bursty loads.

NoSQL Approach (Document Store)

With a document store, you store exactly the data you receive.

Advantages

Add new fields without altering the schema—simply include them in the JSON.
Easy horizontal scaling.
High write throughput.

Common drawbacks

Potential lack of consistency—even with transactions—and schema divergence can occur, though some databases now offer schema validation.
Joins across collections are less powerful and can be slower than SQL joins.

When to Choose a NoSQL Database

Evolving schema: Your data model changes frequently.
High-velocity or high-volume writes: Sensor data, logs, clickstreams.
Geographically distributed scale: You need to shard reads/writes across regions.
Unstructured or semi-structured data: JSON, XML, nested arrays.

If your application requires strict ACID guarantees across multiple tables, complex joins, or you have a stable, rigid schema, SQL is still the best choice.

Conclusion

NoSQL isn’t “better” than SQL; it’s different. As software engineers, we must choose the right tool for the job:

SQL for complex transactions, relational integrity, and stable schemas.
NoSQL for flexible, high-throughput, schema-light workloads.

In our IoT heartbeat example, a document store lets you start quickly, evolve your data model, and handle bursts of sensor data without heavy migrations.

Did you enjoy this primer? Let me know in the comments or follow me for more database deep dives!