Redis Use Cases: Caching, Rate Limiting, Pub/Sub, Queues, and Session Storage

In early 2025, a well-funded fintech startup contacted JusDB with a familiar problem. They had built their core lending platform on MongoDB, drawn in by the promise of flexible schemas and fast iteration. Eighteen months later, their document model had grown into a sprawling tangle of nested arrays — loan applications embedding borrower profiles embedding employment histories — and every reporting query that touched more than one collection required either a $lookup pipeline or a round-trip through their application layer. The engineering team had spent three weeks debugging a multi-document transaction that was silently failing under concurrent load. Their VP of Engineering opened the conversation with: "We think we chose the wrong database." The honest answer, as it usually is, was more nuanced than that.

MongoDB and PostgreSQL are both mature, production-grade databases in 2026. The real question is not which one is better — it is which one fits your data model, your consistency requirements, and your team's operational posture. This guide cuts through the marketing noise and focuses on the concrete trade-offs that matter when you are making or revisiting that choice today.

Background

PostgreSQL has been in continuous development since 1996 and is governed by the PostgreSQL Global Development Group, a non-profit volunteer organization. It is released under the PostgreSQL License, a permissive BSD-style license that places no restrictions on use, modification, or redistribution — including by cloud providers. PostgreSQL 17, released in September 2024, extended its lead in standards compliance, JSON path support, and performance for mixed workload clusters.

MongoDB was founded in 2007, went public in 2017, and ships its database engine under the Server Side Public License (SSPL). The SSPL requires any organization offering MongoDB as a service to open-source their entire service stack — a condition broad enough that Amazon, Google, and other cloud vendors forked the codebase at version 4.2 to create DocumentDB, Cosmos DB, and Ferretdb rather than comply. MongoDB 8.0, released in 2024, brought meaningful improvements to query planning, time-series collections, and the Atlas Search integration.

Both databases run on every major cloud. PostgreSQL is available as Amazon RDS, Amazon Aurora, Google Cloud SQL, Azure Database for PostgreSQL, Supabase, Neon, and dozens of other managed services. MongoDB's managed offering, Atlas, is the de-facto standard for hosted MongoDB and runs across AWS, GCP, and Azure.

Data Model Differences

The most meaningful difference between MongoDB and PostgreSQL is not performance — it is how each database thinks about structure.

PostgreSQL is relational. Data lives in tables with rows and typed columns. Relationships are expressed as foreign keys and joined at query time. Schema changes require ALTER TABLE migrations. This rigidity is intentional: the database enforces consistency that your application code does not have to.

MongoDB is document-oriented. Data lives in collections of BSON documents. Each document is a JSON-like object that can contain nested objects, arrays, and arrays of objects. There is no enforced schema by default — documents in the same collection can have completely different shapes. Schema validation can be layered on via JSON Schema validators, but it is opt-in.

Where Document Model Wins

The document model genuinely excels in three scenarios. First, when your entity has a natural hierarchical structure that does not benefit from normalization — a product catalog with highly variable attributes per category, for example, where a laptop has 40 technical specifications and a t-shirt has 6. Second, when your access pattern almost always retrieves the entire entity and you rarely need to query sub-fields in isolation. Third, when your schema evolves rapidly during early-stage development and you cannot afford migration overhead.

Where Relational Model Wins

The relational model wins when your data has meaningful relationships between entities that need to be queried from multiple directions. A lending platform that needs to ask "show me all loans associated with borrowers who have had a default event in the last 24 months" is working against a document model, not with it. It also wins when data integrity matters — referential integrity, uniqueness constraints, and check constraints are first-class citizens in PostgreSQL and afterthoughts in MongoDB.

PostgreSQL JSONB as a Document Store

Since PostgreSQL 9.4, the JSONB column type stores JSON as a decomposed binary format that supports indexing, path queries, and containment operators. In 2026, PostgreSQL with JSONB is a legitimate competitor to MongoDB for many document workloads — not a workaround.

-- Store variable product attributes in JSONB alongside typed columns
CREATE TABLE products (
    id          BIGSERIAL PRIMARY KEY,
    sku         TEXT NOT NULL UNIQUE,
    name        TEXT NOT NULL,
    category    TEXT NOT NULL,
    price_cents INTEGER NOT NULL,
    attributes  JSONB,
    created_at  TIMESTAMPTZ DEFAULT now()
);

-- GIN index enables fast containment queries on the JSONB column
CREATE INDEX idx_products_attributes ON products USING GIN (attributes);

-- Query: find all laptops with at least 32GB RAM and NVMe storage
SELECT id, name, price_cents
FROM products
WHERE category = 'laptop'
  AND attributes @> '{"ram_gb": 32, "storage_type": "nvme"}';

This approach gives you document flexibility on a per-column basis while keeping the rest of your schema fully relational. You can enforce NOT NULL, add foreign keys to other tables, and join against the typed columns at full SQL speed.

Feature Comparison

Performance Characteristics

ACID Transactions

PostgreSQL's MVCC (Multi-Version Concurrency Control) is woven into every single operation. Every INSERT, UPDATE, and DELETE is transactional without any additional configuration or API ceremony. Concurrent readers never block writers; concurrent writers use row-level locks. This model has been hardened over decades of production use.

MongoDB's single-document atomicity is genuinely powerful — updating a document with nested arrays atomically is something PostgreSQL requires a transaction for. But multi-document transactions, introduced in MongoDB 4.0, require explicit session management and carry a measurable performance overhead. MongoDB's own documentation recommends avoiding multi-document transactions when a schema redesign can eliminate them. In high-contention scenarios, MongoDB's WiredTiger storage engine can exhibit lock escalation that surprises teams coming from PostgreSQL.

Aggregation and Analytics

MongoDB's aggregation pipeline is expressive for document-native transformations — $unwind on nested arrays, $group with accumulator operators, $lookup for cross-collection joins. For workloads that stay within the document paradigm, it performs well.

PostgreSQL's SQL analytics toolset is substantially more powerful for relational analysis. Window functions (ROW_NUMBER, LEAD, LAG, NTILE, running totals) operate over arbitrary partitions and orderings. Recursive CTEs handle graph traversal. GROUPING SETS, CUBE, and ROLLUP produce multi-dimensional aggregations in a single pass. Lateral joins allow correlated subqueries that reference outer rows.

-- PostgreSQL: 30-day rolling revenue by product category
-- This class of query requires multiple pipeline stages in MongoDB
SELECT
    category,
    date_trunc('day', created_at)                           AS day,
    SUM(amount_cents)                                       AS daily_revenue,
    SUM(SUM(amount_cents)) OVER (
        PARTITION BY category
        ORDER BY date_trunc('day', created_at)
        ROWS BETWEEN 29 PRECEDING AND CURRENT ROW
    )                                                       AS rolling_30d_revenue
FROM orders
WHERE created_at >= now() - INTERVAL '90 days'
GROUP BY category, date_trunc('day', created_at)
ORDER BY category, day;

Horizontal Scaling

MongoDB was designed for horizontal scaling from the beginning. Its sharding architecture — splitting collections across shards by a shard key — is a first-class feature that does not require third-party extensions. For write-heavy workloads exceeding what a single server can handle, MongoDB's sharding story is more mature and operationally simpler than PostgreSQL's options.

PostgreSQL scales horizontally through declarative table partitioning (range, list, hash), the Citus extension (which transforms PostgreSQL into a distributed database), and read replicas for read-heavy workloads. Aurora PostgreSQL adds multi-master write scaling. These options are powerful but require more deliberate architecture decisions than MongoDB's built-in sharding.

When to Choose Each

Choose MongoDB When

• Your data is genuinely hierarchical and deeply nested, and you almost always access the entire document as a unit (e.g., a CMS with richly structured content blocks, an IoT platform storing sensor event payloads with variable schemas per device type).
• Your schema changes very frequently and migration downtime or coordination cost is a hard constraint — such as during a rapid MVP phase where the data model is still being discovered.
• Your primary read pattern is fetching a single entity by ID with all its nested data, and cross-entity queries are rare or can be handled by denormalization.
• You are writing to Atlas and need its integrated full-text search (backed by Apache Lucene) or Atlas Vector Search without managing a separate service.
• Your team has significant existing MongoDB expertise and the migration cost to PostgreSQL is not justified by the technical benefits.

Choose PostgreSQL When

• Your data has meaningful relationships between entities that need to be queried from multiple directions — users to orders to products to vendors, for example.
• Data integrity matters: referential integrity, uniqueness constraints, check constraints, and foreign keys should be enforced by the database, not your application code.
• You need complex analytics: reporting queries, aggregations across multiple entity types, window functions, or multi-table joins that span the breadth of your data model.
• You want the operational simplicity of one database for both transactional and analytical workloads, with JSONB available for the genuinely variable parts of your schema.
• Licensing flexibility matters — you want to self-host, switch providers, or run on a managed service without SSPL constraints.
• You are building on Supabase, Neon, or any ecosystem that provides authentication, row-level security, and real-time subscriptions on top of PostgreSQL.

Migration Considerations

If you are moving from MongoDB to PostgreSQL, you have two approaches: migrate to JSONB first, then normalize over time; or normalize directly as part of the migration.

JSONB Migration Path

The fastest migration path is to dump your MongoDB collections as JSON and load them into PostgreSQL as JSONB columns. This gets you onto PostgreSQL immediately — with its licensing, tooling, and operational ecosystem — while deferring the schema work.

-- Temporary JSONB landing table for MongoDB documents
CREATE TABLE mongo_orders_raw (
    id   BIGSERIAL PRIMARY KEY,
    doc  JSONB NOT NULL
);

-- After load, query to understand the shape of your data
SELECT
    doc ->> 'status'                    AS status,
    COUNT(*)                            AS count,
    AVG((doc ->> 'total_cents')::int)   AS avg_total
FROM mongo_orders_raw
GROUP BY doc ->> 'status';

From there, you can incrementally extract typed columns for the fields you query most frequently, add indexes, and introduce foreign keys as you understand your access patterns. The JSONB column becomes a shrinking catch-all as normalization proceeds.

Direct Normalization

Direct normalization produces a cleaner result but requires more upfront analysis. Map each MongoDB collection to one or more PostgreSQL tables. Identify nested arrays that should become child tables with foreign keys. Identify fields that should be typed columns versus candidates for a remaining JSONB attributes column. Write migration scripts that transform documents into relational rows, validate referential integrity, and backfill any derived fields.

For tools, mongodump with --out to JSON followed by a custom ETL script is the most reliable path. Avoid generic migration tools that attempt to auto-map documents to tables — the heuristics are rarely correct for non-trivial schemas.

Key Takeaways

Working with JusDB on PostgreSQL and MongoDB

JusDB works with engineering teams at every stage — whether you are choosing a database for a greenfield project, auditing an existing architecture, or planning a migration. For PostgreSQL workloads, our PostgreSQL managed services cover performance tuning, schema design, query optimization, and production DBA support. For MongoDB-to-PostgreSQL migrations, we handle the full arc: schema analysis, ETL design, cutover planning, and post-migration validation.

If you are unsure which database fits your workload, or if you are experiencing performance or consistency issues with your current setup, reach out to the JusDB team. We will start with an honest assessment of your data model and access patterns before recommending anything.

Related Articles

• PostgreSQL JSONB vs JSON: Indexing Performance Deep Dive — how GIN, GiST, and B-tree indexes work on JSON data, with benchmark comparisons for common query patterns.
• MongoDB Explained: A Complete Guide for Modern Applications — document modeling, aggregation pipelines, indexing strategies, and Atlas features for teams building on MongoDB today.
• The Ultimate Guide to Choosing the Right Database for Your Application — a broader framework for database selection covering PostgreSQL, MongoDB, Redis, Cassandra, and purpose-built databases for 2026 workloads.