Just Use Postgres: The Radical Simplicity of Database-First Architecture

In the ever-evolving landscape of software architecture, a counterintuitive philosophy has been gaining traction among early-stage startups and solo developers: Just Use Postgres. This approach, championed by developers like Stephan Schmidt and embraced by practitioners like Matt Nunogawa, challenges the conventional wisdom that every problem requires its own specialized tool.

The Core Philosophy

The fundamental premise is deceptively simple: shift complexity away from DevOps and into code. Rather than building an intricate web of microservices, message queues, and specialized databases, the "Just Use Postgres" philosophy advocates for consolidating as much functionality as possible into a single, well-understood database system.

This isn't about being dogmatic or refusing to use better tools when they're truly needed. It's about recognizing that every additional service you add to your stack comes with hidden costs: another deployment target, another failure point, another thing for new developers to learn, and another source of late-night pager alerts.

What Postgres Can Replace

The power of this approach lies in Postgres's surprising versatility. Here's what many teams find they can eliminate:

Search Engines

Elasticsearch and Typesense are often the first casualties. Postgres has had full-text search capabilities for years, and with trigram matching (using the pg_trgm extension), it can handle fuzzy search queries that would traditionally require a dedicated search engine. For early-stage products, this is often "more than good enough."

Message Queues

Redis and RabbitMQ can be replaced with Postgres itself. Using SELECT ... FOR UPDATE SKIP LOCKED, you can create reliable, transactional work queues without introducing another service. Sequin's writeup on building your own SQS or Kafka with Postgres demonstrates just how far you can push this pattern.

Caching Layers

Redis and Memcached become less critical when you leverage Postgres's capabilities. JSONB columns can store semi-structured data, materialized views can precompute expensive queries, and unlogged tables work well for ephemeral data. The side benefit? When your data and cache live on the same machine, you eliminate entire classes of cache invalidation headaches.

Key-Value Stores

MongoDB and other NoSQL databases often fall away when you realize that JSONB columns are essentially a schemaless key-value store that also supports indexing and querying. It's not as fast as Redis for hot-path lookups, but it's more durable and dramatically simpler.

The Real-World Results

Matt Nunogawa's experience validates this approach. Starting a greenfield project with Elixir, Phoenix, and LiveView on top of Postgres, he found that this setup would "likely last me through my next two or three engineering hires." Two years later, with a team of five engineers, they were only now moving away from the "Just Use Postgres" philosophy—and even then, they were still "mostly using Postgres."

The benefits were clear: simplicity of deployment, speed of iteration, and the ability to reason about the entire system. New developers could get the full stack running on their laptops in minutes, not days. The operational overhead was minimal, allowing the team to focus on features that mattered to customers rather than infrastructure plumbing.

When It Breaks Down

This isn't a universal panacea. There are legitimate reasons to introduce specialized services:

• When search queries start taking hundreds of milliseconds and indexing options are exhausted
• When processing tens of thousands of jobs per second requires a real message broker
• When sub-millisecond cache lookups at massive scale justify Redis's complexity

But here's the crucial insight: you'll know when you get there. And when you do, you'll be migrating one well-understood component at a time, not untangling an operational ball of spaghetti.

The Hidden Cost of "Best Tool for the Job"

The conventional wisdom says to use the best tool for each job. But this advice has a hidden cost that's rarely acknowledged: every tool you add is another thing that can break, another thing to deploy, another thing new hires need to learn, and another thing keeping you up at night.

The "best tool for the job" is often the tool you already have running, as long as it can do the job. Postgres can do a surprising number of jobs. Not all of them optimally. But at early stage, optimal doesn't matter. Speed of iteration matters. Simplicity of deployment matters. Being able to reason about your entire system matters.

The Broader Principle

This philosophy is an application of a broader principle that's been discussed in software architecture for years: simple as possible, as few components as possible. "Just Use Postgres" is that principle taken seriously. It's about recognizing that complexity has a compounding cost that's often invisible until it's too late.

The AI Factor

An interesting update from 2026: AI and LLMs are unreasonably good at querying JSONB columns. They're good at SQL in general, but if Postgres's somewhat odd JSONB syntax bothered you, AI makes it easier. This suggests that the gap between specialized tools and Postgres's general-purpose capabilities may continue to narrow.

The Bottom Line

If you're early stage, start with Postgres. Use it for everything you can. Add complexity only when your scale forces your hand. You'll ship faster, sleep better, and (hopefully) spend your limited engineering bandwidth on stuff that actually matters to your customers.

In a world obsessed with microservices, specialized databases, and architectural purity, "Just Use Postgres" is a refreshing reminder that sometimes the simplest solution is also the best solution. And in the early days of a startup, when you're racing against time and limited resources, that simplicity might be the difference between success and failure.