For years, the industry followed a rigid, almost religious playbook. If your data grew too large for a relational database, you moved the read heavy workloads to NoSQL. We called it Command Query Responsibility Segregation (CQRS). We told ourselves that the architectural complexity was just a necessary tax for performance. But lately, a new wave of senior engineers is looking at the latest Postgres features and asking a dangerous question. Why are we maintaining two separate database systems when one can do the job better?
This shift toward consolidation is best seen in a recent migration documented by developer Bohdan Stupak. While working on a high scale system, his team initially followed the standard CQRS manual. They used PostgreSQL as the primary source of truth for writes and a NoSQL database as the optimized layer for reads. It was a classic setup, but it came with a persistent headache. Keeping those two worlds in sync is never as simple as the diagrams suggest.
The Complexity Tax of Distributed Data
When you split your data between a relational write store and a NoSQL read store, you enter a world of eventual consistency and synchronization debt. You are no longer just a developer. You are a distributed systems janitor.
Stupak notes that his team even had to maintain a special safety mechanism, which was a dedicated endpoint designed to regenerate the entire NoSQL storage from the Postgres source. This is the ultimate fallback for when the sync inevitably breaks. If you have to build a tool to rebuild your entire secondary database because you do not trust the synchronization, your architecture is screaming for a simpler approach. The goal was to reduce query latency, but the cost was a massive increase in maintenance and operational risk.
Enter the Native Power Up: pg_partman and pg_cron
Instead of offloading the burden to a separate NoSQL cluster, the alternative is to make Postgres work harder. The solution involves moving away from monolithic, bloated tables and adopting native partitioning. This is where pg_partman and pg_cron come into play.
Think of a massive database table like a giant, disorganized warehouse. The more you put into it, the longer it takes to find anything. Partitioning turns that warehouse into a series of organized shipping containers. By breaking a large table into smaller, more manageable chunks based on a specific key (like time or ID), the database engine can ignore 99 percent of the data and focus only on the relevant partition.
pg_partman acts as the automated warehouse manager. It handles the creation of new partitions and the retirement of old ones, removing the manual toil that usually makes partitioning a chore for DBA teams. But even the best manager needs a schedule. That is where pg_cron enters the stack. It allows for job scheduling directly within the database, ensuring that maintenance tasks happen like clockwork without needing an external cron server or a complex Lambda function to trigger updates.
DX and the Return to Simplicity
From a developer experience (DX) perspective, this is a massive win. You stay within the SQL ecosystem and keep your ACID guarantees. You do not have to learn a new query language or manage the quirks of a NoSQL engine.
More importantly, you eliminate the "sync gap" entirely. Your source of truth is also your high performance read layer.
Stupak reported that this transition allowed the team to drastically reduce query time for a large table. While the specific benchmarks were not detailed in the initial report, the architectural implications are clear. By utilizing native tools, the team moved closer to a single database reality. They kept the safety endpoint for peace of mind, but the primary engine was now capable of handling the load that previously required a separate NoSQL instance.
Is the NoSQL Read Model Dying?
As a senior developer who has spent a decade watching the pendulum swing between SQL and NoSQL, this feels like a significant correction. We are seeing a "Return to Postgres" movement. With the advent of better partitioning tools and built-in scheduling, many of the reasons we fled to NoSQL in 2015 are simply gone.
Postgres is no longer just a place to store rows. It is an extensible platform that is slowly consuming the niche use cases that once justified bloated, multi database architectures. If you can achieve the same query performance with a partition as you can with a NoSQL document store, why would you ever double your infrastructure bill?
We need to stop treating NoSQL as the default answer for scale. The real question for 2024 and beyond is not how to sync your databases, but how to use the power already sitting inside your relational engine. As PostgreSQL continues to refine its native partitioning, the traditional NoSQL heavy CQRS pattern might finally be reaching its expiration date. Are you overengineering your stack, or are you letting your database do the job it was built for?
