Redis vs pg-boss: Why I Chose PostgreSQL Job Queues

Spend enough time watching software development videos on TikTok or YouTube, and you might begin to believe that your web application is incomplete without Redis. Whether the discussion is about background jobs, application performance, or scalability, Redis frequently appears as a recommended solution. Some tutorials present it with such confidence that developers could easily assume it's an essential component of every modern web application.

But recommendations, however popular, don't necessarily reflect the requirements of the application you're building.

I found myself confronting this question while evaluating the architecture of a web application I was developing. The application required reliable background processing, but I was equally concerned about introducing unnecessary complexity into infrastructure that already had several components to manage. Redis was one of the technologies I considered, alongside pg-boss, a background job queue built for Node.js applications using PostgreSQL.

After examining the application's requirements, existing infrastructure, and the operational implications of both approaches, I chose pg-boss. My decision wasn't based on the assumption that Redis was inferior, nor was it an attempt to prove that PostgreSQL-backed queues outperform Redis. Rather, the evaluation showed that, at this stage of development, the application didn't have requirements that justified introducing Redis specifically for background processing.

That experience reinforced an important principle in how I approach web development and systems integration: the best technology isn't necessarily the most popular. It's the one that addresses your actual requirements without introducing complexity you cannot justify.

I believe this distinction deserves more attention, particularly as developers increasingly encounter architectural recommendations through short-form technical content.

The Problem With Developing Around Hype

Social media has become a valuable learning resource for developers. Platforms such as YouTube and TikTok expose us to new frameworks, libraries, infrastructure tools, and architectural approaches that might otherwise take considerable time to discover. I regularly explore these resources myself, and I believe they have an important place in continuous professional development.

However, the limitations of short-form technical content become apparent when complex architectural decisions are reduced to universal recommendations. A developer might demonstrate how Redis improves performance in a high-traffic application, while another explains how BullMQ handles background jobs using Redis. Both demonstrations may be technically accurate, but neither necessarily establishes that Redis is appropriate for every application.

The missing ingredient is often context.

An architecture designed to support millions of requests may have very different requirements from a management system serving a relatively small organisation. Both applications need reliability, security, and maintainability, but their infrastructure requirements, operational budgets, and expected workloads can differ significantly. Adopting the same technologies without examining those differences can introduce complexity that delivers little practical benefit.

This is where I think developers need to exercise greater judgement. Learning how a technology works is valuable, but understanding when to use it is an entirely different responsibility. If we allow trends to determine our architecture, we risk building systems around someone else's problems rather than the needs of our own applications.

Scalability should be informed by requirements and evidence, not by the assumption that more infrastructure automatically produces a better application.

My Experience: Evaluating Redis Against What the Application Actually Needed

When I began evaluating background processing options, my starting point was the application's existing architecture. I was working within a Node.js environment where PostgreSQL was already serving as the primary database. The application needed certain operations to run independently of user-facing requests, and I wanted an approach that would support reliable execution without adding unnecessary operational responsibilities.

Background processing is important because not every application task should be executed while a user waits for a response. Sending notifications, generating reports, processing scheduled activities, and communicating with external services are examples of operations that can often be handled asynchronously. A properly designed background job system allows these activities to be managed independently, with mechanisms for tracking execution, retrying failures, and recovering from interruptions.

My evaluation therefore focused on the problem of reliable background processing rather than the broader capabilities of Redis. I wanted to understand whether introducing a separate Redis-backed queue was necessary when PostgreSQL was already available.

Option One: Introducing Redis

Redis was a reasonable technology to consider because it supports established background job solutions such as BullMQ. A Redis-backed architecture can provide reliable asynchronous processing and allow queue workloads to be managed separately from the application's primary database. Redis also offers capabilities beyond queue management, including caching, session storage, and messaging.

Those advantages were relevant to the evaluation, but so were the operational implications. Introducing Redis for this application would mean adding another service dependency, along with the associated configuration, security, monitoring, maintenance, and recovery considerations. I needed to establish whether the application's requirements were sufficient to justify those responsibilities.

Option Two: Using PostgreSQL With pg-boss

The alternative was to use pg-boss, which coordinates background jobs through PostgreSQL. Because the application already depended on PostgreSQL, this approach would allow me to introduce reliable background processing without deploying Redis specifically for queue management.

That did not mean background processing would become effortless or consume no additional resources. Workers would still need to be configured and monitored, failed jobs would require appropriate handling, and PostgreSQL would absorb the additional queue activity. Nevertheless, the architecture would build upon a database I was already managing rather than introducing a separate data service.

After considering both options, I found that pg-boss provided the capabilities the application required at that stage. I therefore selected it as the more appropriate solution.

It is important to distinguish this conclusion from a performance benchmark. I wasn't establishing that pg-boss was faster than Redis or that it would consume fewer resources under every workload. My evaluation was about architectural suitability: whether the additional complexity of Redis was justified by what the application actually needed.

At the time, I couldn't establish a sufficiently compelling reason to introduce it.

Redis vs. pg-boss: Understanding the Architectural Difference

Although Redis and pg-boss can both form part of a background processing architecture, they are not identical technologies. Understanding their different purposes is essential before attempting to compare them.

What Is Redis?

Redis is a high-performance data platform commonly used for caching, messaging, session management, rate limiting, and other operations requiring fast data access. Its in-memory architecture makes it particularly useful for applications that need to retrieve or update frequently accessed information with low latency.

Consider an application that repeatedly performs expensive database queries to retrieve information that changes infrequently. A Redis caching layer may reduce unnecessary database operations and improve response times. Redis can also support background job processing through tools such as BullMQ, allowing applications to distribute work across multiple workers.

These capabilities make Redis valuable in many production environments. However, its usefulness across different scenarios does not mean every application requires all those capabilities.

What Is pg-boss?

pg-boss is a background job queue designed for Node.js applications using PostgreSQL. It enables developers to schedule, process, retry, and manage asynchronous tasks while using PostgreSQL as the underlying job store.

One of its important technical features is its use of PostgreSQL's SKIP LOCKED mechanism, which allows multiple workers to claim different jobs without unnecessarily blocking one another. This supports concurrent background processing while taking advantage of PostgreSQL's transactional capabilities.

Another useful feature is the ability, when correctly implemented, to create a background job within the same database transaction as the associated application data change. This can help maintain consistency between business operations and the jobs they trigger.

For applications that already use PostgreSQL, these capabilities make pg-boss a practical option worth evaluating before adding a separate Redis-backed queue.

How Do They Compare in Practice?

The fundamental distinction is that Redis is a broader data platform, while pg-boss is specifically designed for PostgreSQL-backed background processing.

A Redis-backed queue, using a tool such as BullMQ, relies on a Redis service. This allows queue activity to be isolated from the application's PostgreSQL database, which can be advantageous when background processing volume increases or when other Redis capabilities are also required.

pg-boss, on the other hand, uses PostgreSQL to coordinate jobs. This reduces the number of distinct data services required when PostgreSQL is already available, although queue activity shares database resources with other application operations.

Redis also provides specialised caching capabilities that pg-boss does not attempt to replace. Comparing them as though they offer identical functionality would therefore be misleading.

For me, the question was not which technology had the longest list of capabilities, but which approach would adequately support the application's current background processing requirements.

Neither technology is universally better. The appropriate choice depends on workload, infrastructure, operational capacity, and the problem being solved.

The Hidden Cost of Introducing Another Infrastructure Dependency

One of the lessons I've learned from managing web applications in production environments is that infrastructure complexity accumulates. A service that takes only a few minutes to install during development may introduce responsibilities that continue for the lifetime of the application.

Every additional dependency needs appropriate configuration, security controls, monitoring, updates, and recovery procedures. When multiple applications are hosted on a shared virtual private server, infrastructure decisions also affect how available computing resources are distributed. This makes it important to evaluate not only whether a service can perform a particular function, but also what it will cost to operate and maintain that service reliably.

Redis illustrates this trade-off. Running it alongside an application introduces a separate process with its own resource requirements, while using a managed Redis service can shift some operational responsibilities to a provider at the cost of an additional external dependency and potentially recurring service charges.

Using pg-boss avoids introducing Redis specifically for background jobs, but it is not without cost. PostgreSQL must handle the additional reads, writes, connections, and job records, while application workers continue to consume computing resources. Depending on workload characteristics, these demands could eventually affect the performance of the primary database.

For that reason, I would avoid claiming that pg-boss automatically reduces CPU or memory consumption compared with Redis. Such conclusions require workload-specific measurements. A simpler architecture may reduce the number of services to manage, but that is different from demonstrating superior performance.

In my evaluation, the objective was to minimise unnecessary operational complexity while retaining the capabilities the application required.

That distinction is particularly relevant when working with organisations whose resources must be allocated carefully. Infrastructure choices affect hosting expenses, maintenance requirements, troubleshooting, system availability, and development time. A technically impressive architecture is of limited value if the complexity it introduces outweighs the benefits it delivers.

The Architecture Audit: Five Questions I Ask Before Adding Another Technology

My experience evaluating Redis and pg-boss reinforced the importance of examining an application's actual requirements before recommending additional infrastructure. Rather than beginning with a preferred technology, I believe it is more productive to begin with a structured assessment of the problem, the existing environment, and the operational implications of the proposed solution.

Five questions have become particularly useful in guiding that assessment.

1. What Problem Are We Actually Trying to Solve?

The first responsibility is to define the problem accurately. Slow application responses, delayed background tasks, inefficient database queries, and difficulties handling concurrent users can have very different causes. Introducing Redis may be appropriate for some of these problems, but it should not be treated as a universal solution.

For example, an application experiencing slow database queries may benefit more from reviewing query execution plans and indexing strategies than from immediately introducing a caching layer. Similarly, an application that simply needs scheduled background processing may not require a dedicated Redis service. Understanding the cause of the problem allows the architecture to address the requirement rather than its symptoms.

2. What Can Our Existing Infrastructure Already Support?

Before introducing another technology, I want to understand whether the existing infrastructure can safely meet the requirement. In my evaluation, PostgreSQL was already available, making pg-boss a relevant option for background processing.

This does not mean every responsibility should be forced onto a single database or service. It means existing capabilities deserve proper consideration before expanding the infrastructure. Reusing an established component can simplify operations when doing so does not compromise performance, reliability, or maintainability.

3. What Does the Performance Evidence Tell Us?

Architecture decisions become more defensible when supported by relevant measurements. Application response times, queue waiting times, background job throughput, database connections, CPU and memory consumption, and failure rates can all help establish whether the current approach remains suitable.

Not every project begins with comprehensive production performance data, particularly during early development. In such cases, requirements analysis, expected workloads, representative testing, and clearly defined monitoring plans can inform the initial decision. As the application grows, actual measurements should increasingly guide architectural changes.

In my case, the available requirements did not establish a need for Redis. That conclusion was sufficient to guide the initial choice, but it was not evidence that pg-boss would outperform Redis in every environment.

4. What Happens When Something Fails?

Reliable background processing requires more than placing tasks in a queue. Developers must consider what happens when a worker crashes, a database connection is interrupted, or an external service becomes temporarily unavailable.

Both Redis-backed queue systems and pg-boss can support job retries and recovery mechanisms, but application logic must also be designed to handle repeated execution safely. pg-boss, for example, uses at-least-once job delivery, meaning that a job handler may execute more than once following certain failures or retries.

This matters particularly for operations involving payments, financial records, or external transactions. A repeated background job should not accidentally create duplicate charges or inconsistent records. These requirements must be addressed through appropriate job design, monitoring, and recovery procedures regardless of which queue technology is selected.

5. What Will This Decision Cost Us to Maintain?

A technology can be freely available and still introduce substantial operating costs. Server resources are only one consideration; security, maintenance, monitoring, recovery planning, developer expertise, and troubleshooting all contribute to the long-term cost of ownership.

This is why I believe architecture decisions should consider the organisation's operational capacity alongside technical requirements. A smaller team may gain considerable value from a simpler system that meets its needs reliably, while a larger application with demanding workloads may justify additional infrastructure to improve performance and isolate critical services.

The objective isn't to choose the cheapest or simplest technology in every situation. It is to ensure that the benefits of the selected approach justify the resources required to operate it.

When I Would Recommend Redis

Although pg-boss was the more appropriate choice for my application at the time, there are circumstances in which I would recommend Redis without hesitation.

An application requiring a shared caching layer across multiple instances may benefit significantly from Redis, particularly when repeated database operations are affecting response times. Redis can also be appropriate for distributed session management, rate limiting, messaging, and other workloads where its data structures and low-latency capabilities provide a clear advantage.

From a background processing perspective, Redis-backed queues may become attractive when job volume or processing patterns justify isolating queue storage from the primary PostgreSQL database. If background jobs begin competing with user-facing database operations for resources, separating those workloads could become an important architectural consideration.

Another factor is the infrastructure an organisation already operates. If Redis is already deployed and maintained for a justified purpose, using it for background processing may be more practical than introducing a separate queue solution.

These examples highlight why I don't believe technology decisions should become permanent rules. A choice that is appropriate during early development may need to be reconsidered as workloads, requirements, and operational capacity change.

The responsibility of an architect isn't to defend an earlier decision indefinitely. It's to recognise when the evidence justifies a different one.

Building for Scale Doesn't Mean Overengineering From Day One

One of the arguments frequently used to justify introducing additional infrastructure early is the possibility of future growth. This concern is understandable because applications that succeed often develop requirements that were not fully anticipated during their initial design.

However, preparing an application for growth does not necessarily require deploying every component it might eventually need. I believe a more sustainable approach begins with clear architectural boundaries, appropriate monitoring, and an understanding of where future constraints may emerge.

For example, business logic should be designed so that it is not unnecessarily dependent on a particular background queue implementation. Workers should be manageable independently, failures should be observable, and database performance should be monitored as workloads increase. These practices can make future architectural changes more manageable without requiring every potential infrastructure component to be introduced immediately.

Moving from a PostgreSQL-backed queue to a Redis-backed system would still require careful engineering, testing, and deployment. Nevertheless, an application designed with separation of concerns is better positioned to accommodate that transition than one where background processing is tightly coupled to business logic.

For me, this is what planning for scalability should involve: understanding the likely direction of growth while remaining disciplined about the infrastructure that is needed today.

What This Experience Reinforced About My Approach to Software Development

Evaluating Redis and pg-boss was ultimately about more than selecting a background job library. It reinforced a broader lesson about the relationship between technology decisions and the value we are expected to deliver as developers and consultants.

When developing or integrating web applications, it is easy to become preoccupied with technical choices. Frameworks, databases, deployment tools, and architectural patterns all deserve careful consideration, but they are not the primary reason organisations invest in software.

Businesses and organisations invest in applications because they need to solve operational problems. They want to manage information more effectively, automate repetitive activities, connect systems, improve accountability, or deliver better experiences to the people they serve. The technologies we recommend should support those objectives rather than become objectives in themselves.

This places a responsibility on developers and technology consultants to look beyond implementation. We need to understand the business context, assess technical requirements, anticipate operational risks, and explain why a particular investment is appropriate.

Sometimes that assessment will justify a more sophisticated architecture. At other times, it will demonstrate that an existing technology already provides what the organisation needs.

Both outcomes require sound technical judgement.

Increasingly, I see the ability to identify unnecessary complexity as an important part of professional expertise. Knowing how to deploy a technology is valuable, but knowing whether it should be deployed in the first place can be equally important.

Final Thought: Don't Let a 60-Second Tutorial Make a Long-Term Architectural Decision for You

I continue to learn from technical tutorials, experiment with new tools, and explore emerging approaches to software development. These resources are useful because they expose us to possibilities we might not have considered. However, I have become more deliberate about separating the discovery of a technology from the decision to introduce it into an application.

A short video can demonstrate what Redis is capable of, but it cannot determine whether Redis belongs in your architecture without understanding the application's requirements, expected workload, existing infrastructure, and operational constraints. That evaluation remains the responsibility of the developer or consultant making the recommendation.

In my case, comparing Redis with pg-boss led me to select PostgreSQL-backed background processing because it was sufficient for the application's requirements at that stage. If those requirements change and the evidence begins to justify Redis, I would have no hesitation in reconsidering the decision.

What matters is that the choice is deliberate, explainable, and grounded in the needs of the system rather than the popularity of a particular tool.

Good software architecture isn't about how many technologies you deploy. It's about how effectively each technology contributes to solving the problem.

Before introducing another service into your application, examine what you already have, understand what the application actually requires, and establish whether the proposed technology offers sufficient value to justify its cost and complexity.

The objective should never be to build the most elaborate system possible. It should be to build the right system for the problem you're solving, with a clear path to evolve when circumstances demand it.

Frequently Asked Questions

Does Every Node.js Application Need Redis?

No. Redis can be valuable for caching, messaging, session management, and background job processing, but it is not a mandatory component of every Node.js application. Whether it is appropriate depends on the application's technical requirements, existing infrastructure, and expected workload.

Can I Run Background Jobs in Node.js Without Redis?

Yes. Node.js applications can use PostgreSQL-backed job queues such as pg-boss to schedule, process, and retry background jobs without deploying Redis. This can be a practical approach when PostgreSQL is already part of the application architecture.

Is pg-boss Better Than Redis for Background Jobs?

Neither approach is universally better. pg-boss can simplify the architecture of an application already using PostgreSQL, while Redis-backed queues such as BullMQ can provide workload isolation and other useful capabilities. The decision should be based on reliability requirements, workload characteristics, and operational considerations.

Can pg-boss Handle Production Workloads?

Yes. pg-boss is designed for production background processing and provides capabilities including scheduling, retries, and concurrent job execution. Its suitability for a specific application depends on workload volume, database capacity, worker configuration, failure handling, and monitoring.

Does Using pg-boss Reduce Server Memory Consumption?

Not necessarily. Avoiding a separate Redis service removes the resource requirements associated with that service, but pg-boss places additional work on PostgreSQL and application workers. The overall performance and resource impact should be established through appropriate monitoring and testing.

When Should I Introduce Redis Into My Web Application?

Redis becomes worth considering when requirements such as shared caching, low-latency data access, queue workload isolation, or distributed messaging justify its capabilities. The decision should follow an assessment of the application's current limitations and expected growth rather than assumptions about what every modern application needs.

Technical References

The following resources provide additional technical information on the technologies discussed:

• pg-boss — Official Documentation
• pg-boss — GitHub Repository
• Redis — Official Use Cases
• BullMQ — Queue Documentation
• PostgreSQL — Explicit Locking Documentation

This article reflects my experience evaluating infrastructure choices during web application development. It is not a comparative performance benchmark or a universal recommendation against using Redis.