Learning Node.js - Relational vs NoSQL Databases in Node.js

#Introduction

Real applications almost always store data, and Node.js can talk to nearly any database. The first question to answer before writing code: which database is right for this problem? The answer is rarely single — many applications use more than one type of database.

Episode 13 builds a framework for choosing: the characteristics of relational databases based on SQL with ACID transactions, the characteristics of NoSQL databases with a flexible document model, and practical considerations when both are used from a Node.js application. We're not writing connections yet — that's the job of episode 14.

#Relational Databases and ACID

#Ordered Structure with a Rigid Schema

Relational databases store data in tables with rows and columns, connected to each other through foreign keys. PostgreSQL, MySQL, and SQLite are the most common examples. Their main strength is integrity: the structure is defined first, and the database enforces its rules.

psql -U postgres -d app_db -c "CREATE TABLE pengguna (id SERIAL PRIMARY KEY, email TEXT UNIQUE NOT NULL, nama TEXT NOT NULL);"

The psql command above creates a pengguna table with the columns id, email, and nama — the UNIQUE NOT NULL constraints ensure there are no duplicate or empty emails. This is the relational hallmark: data can't get in if it violates the schema.

#Transactions and ACID Properties

The main strength of relational databases is transactions with ACID properties:

• Atomicity: all operations succeed or fail together.
• Consistency: data always satisfies the database rules.
• Isolation: transactions run separately from one another.
• Durability: data survives even if the server crashes.

Consider a money transfer: the deduction in one account and the addition in another must happen together. This property keeps relational databases the primary choice for financial systems, orders, and data that must be consistent.

#NoSQL Databases and the Document Model

#Flexibility Without a Rigid Schema

NoSQL databases come in several forms: document (MongoDB), key-value (Redis), wide-column (Cassandra), and graph (Neo4j). The one most often used with Node.js is the document database because it stores JSON naturally:

Document in MongoDB

const pengguna = {
  nama: "Arman",
  email: "arman@contoh.com",
  alamat: { kota: "Bandung", negara: "Indonesia" },
  hobi: ["coding", "membaca"],
};

Notice the difference from a table: documents can have different structures, including nested fields like alamat and arrays like hobi. Because Node.js speaks JSON, data can be stored and read with almost no conversion — this is why MongoDB has long been popular in the Node.js ecosystem.

#When NoSQL Excels

NoSQL suits data whose schema changes rapidly, whose shape is irregular, or whose write volume and speed are very high. Examples: event logs, user profiles with dynamic attributes, product catalogs with varying specifications, and real-time data.

#Choosing Considerations in Node.js

#Three Questions Before Choosing

A database decision doesn't come from trends, but from needs. Ask three things:

• Data integrity: must the data always be consistent and transactional? If so, choose relational.
• Data shape: is the data structure fixed and known? Relational excels. Flexible and nested? Document fits.
• Access scale: is the workload read-heavy, write-heavy, or analytical? Each database type has different strengths.

Honest answers to these three questions almost always point to the right choice. It's very common to see Node.js applications using PostgreSQL as the source of truth and Redis as a cache — both for different tasks.

#Not Black and White

The boundary between relational and NoSQL is increasingly blurred. PostgreSQL now supports the jsonb type for semi-structured data, while MongoDB supports multi-document transactions and secondary indexes. The best choice is often a combination — what matters is that you understand the basic strengths of each.

#Accessing Both from Node.js

#Databases Don't Care About Language

Drivers and ORMs make the difference between the two barely noticeable when writing code. SQL queries are sent through drivers like pg, while MongoDB is used through the official mongodb client — both are called from the same JavaScript language:

Query from Node.js

import pg from "pg";
 
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });
const hasil = await pool.query("SELECT * FROM pengguna WHERE id = $1", [1]);
console.log(hasil.rows[0]);

pool.query("SELECT * FROM pengguna WHERE id = $1", [1]) sends a parameterized query to PostgreSQL. Notice the $1 placeholder, which prevents injection — a pattern we'll maintain in episodes 14 and 20.

What matters in this episode isn't the driver syntax, but the architectural decision behind it: choosing relational or NoSQL determines the schema shape, query approach, and scaling strategy. This decision should be made before writing much code, because switching databases mid-way is very expensive.

#Decision Summary

#A Mental Comparison Table

• Relational: structured data, transactional requirements, complex relations, analytical reports.
• Document: flexible data, fast prototyping, semi-structured data, horizontal scaling.
• Redis: cache and short-lived state (to be discussed in episode 16).

In episode 14 we'll take PostgreSQL as an example and connect it to a Node.js application. The patterns used — connection strings, pooling, and queries — apply to almost all drivers.

#Closing

Here's what to take away:

• Relational databases use tables with a rigid schema and ACID transactions.
• NoSQL documents store flexible JSON that fits Node.js.
• ACID transactions matter for financial and must-be-consistent data.
• The database choice follows integrity, data shape, and access patterns.
• PostgreSQL with jsonb and MongoDB with transactions blur the boundary.
• Real applications often use a combination of databases for different tasks.

In the next episode, episode 14, we'll discuss database connections with drivers or ORMs — using the pg driver with a connection pool, comparing it with the Prisma ORM, managing connection strings via the environment, and running migrations. You'll connect Node.js to a real database.