Stephan Schmidt - Updated: September 5, 2025

Just Use Postgres for Everything

Replace Redis, MongoDB, Kafka & more with PostgreSQL. Reduce complexity, boost development speed. Simplify your stack.

TLDR; just Postgres for everything.

We have invited complexity through the door. But it will not leave as easily.

One way to get complexity out of the door, is simplifying your stack. Reduce the moving parts, speed up development, lower the risk and deliver more features in your startup is “Use Postgres for everything”. Postgres can replace—up to millions of users—many backend technologies, Kafka, RabbitMQ, Mongo and Redis among them. This makes every application easier to develop, scale and operate.

Less moving parts means fewer developers for parts that don’t provide value or just replicate existing functionality (frontend) and more developers on parts (like the backend) that does provide value to customers. What if you could increase feature output without higher costs? For developers: What about a lower cognitive load? You really deeply understand all moving parts? No more imposter syndrome?

What is PostgreSQL?

PostgreSQL (Postgres) is an open-source relational database management system that supports both SQL and NoSQL workloads. Unlike specialized databases, Postgres can serve as a cache, message queue, document store, analytics engine, and more - making it an ideal choice for reducing technology stack complexity.

TLDR: Just use Postgres for everything up to millions of users.

Why Choose PostgreSQL Over Multiple Specialized Tools?

Startups typically use Redis for caching, MongoDB for documents, Kafka for messaging, and Elasticsearch for search - creating operational overhead, multiple failure points, and cognitive load for developers.

PostgreSQL can replace most of these specialized tools for applications serving up to millions of users, delivering:

• faster feature development
• reduced operational overhead
• single point of expertise instead of multiple technologies
• unified monitoring, backup, and scaling strategies

Just Use Postgres

Caching instead of Redis

Use Postgres with UNLOGGED tables and TEXT as a JSON data type. Use stored procedures or do as I do, use ChatGPT to write them for you, to add and enforce an expiry date for the data just like in Redis.

Message queue instead of Kafka

Use Postgres as a message queue with SKIP LOCKED (if you only need a message queue). Or as a job queue in Go with River

Data warehouse

Use Postgres with Timescale as a data warehouse. Use DuckDB for S3 integration.

Data lake

Use Postgres together with DuckDB as a data lake. There is a product for this called DuckLake, with Postgres as the catalog.

In-memory OLAP

Use Postgres with pg_analytics as an in memory OLAP with Apache Datafusion

Document database instead of MongoDB

Use Postgres with JSONB to store Json documents in a database, search and index them. If you need a more drop-in like replacement, use DocumentDB.

Cron daemon

Use Postgres as a cron demon to take actions at certain times, like sending mails, with pg_cron adding events to a message queue.

Geospatial queries

Use Postgres for Geospatial queries.

Full-text search instead of Elastic

Use Postgres for Fulltext Search.

JSON API generation

Use Postgres to generate JSON in the database, write no server side code and directly give it to the API.

Auditing

Use Postgres with auditing with pgaudit

GraphQL delivery

Use Postgres with a GraphQL adapter to deliver GraphQL if needed.

Vector database

Use Postgres with pgvector for embeddings and AI similarity search instead of specialized vector databases.

Session store

Use Postgres for web session management instead of Redis with proper indexing on session IDs and expiration timestamps. Use hstore for a key value store. s Rate limiting

Use Postgres for API rate limiting with atomic updates and time-based windows instead of Redis counters.

Distributed locks

Use Postgres advisory locks for coordination between processes and services.

Event sourcing

Use Postgres for event-driven architectures with proper ordering and atomic event storage.

Testing database

Use Postgres transactions for ephemeral test databases, rolling back after each test for clean state. Use Postgres template databases for fast and easy database creation for tests.

Metrics and monitoring

Use Postgres with pg_stat_statements for application performance metrics.

Webhooks

Use Postgres with HTTP extensions to send HTTP notifications on data changes.

File storage metadata

Use Postgres for file metadata and large object storage instead of separate file management systems.

Secure cryptography

Use pgcrypto for secure cryptography.

Scale with Postgres

Scaling databases often happens with partitioning. Use Postgres partman to scale your database.

Multi-tenancy

Use Postgres row-level security for SaaS applications with tenant isolation.

Scheduled jobs

Use Postgres with pg_timetable for complex job scheduling beyond simple cron.

Postgres is becoming like Linux. Linux replaced all the other unix/bsd based operating systems into one system - OpenBSD still exist are great, they bring great ideas but have in the grand scheme of things have neglectable market share to the point many people haven’t heard of them. Linux has a development model with modules and userland code, where everyone can participate - and new inventions in operating systems can be implemented. The same way Postgres absorbs good ideas of other databases and implements them in a way that is easy to use in existing code bases. With the marketing power and reach of Postgres.

There I’ve said it, just use Postgres for everything.

How to Install PostgreSQL Extensions

PostgreSQL’s power comes from its extensive extension ecosystem. Here’s how to install extensions to unlock Postgres’s full potential:

1. Connect to the PostgreSQL database

First, connect to your PostgreSQL database using the psql command-line tool or any PostgreSQL client:

psql -U username -d database_name

Replace username with your PostgreSQL username and database_name with your database name.

2. Check for available extensions

List all available extensions to see what’s ready to install:

SELECT * FROM pg_available_extensions;

3. Install the extension

Install an extension using the CREATE EXTENSION command:

CREATE EXTENSION extension_name;

For example, to install the pgvector extension for key-value pairs:

CREATE EXTENSION vector;

4. Verify the installation

Confirm the extension installed correctly:

SELECT * FROM pg_extension;

FAQ

Q: But what about single points of failure? A: You mean like having five different systems that can each break? Right now you have Redis, Kafka, and MongoDB. That’s three points of failure, not one. SLAs drop fast, with three systems at 99.9% each, the SLA is 99.7%. With Postgres, you have one system at 99.9%, and you’re done.

Q: Won’t Postgres be too slow for caching/messaging? A: Instagram uses Postgres. They have more users than you. Your startup with 10,000 users doesn’t need Redis performance. You need developer productivity and operational simplicity. When you actually hit Postgres limits—not when you think you will—then add specialized tools.

Q: My senior developers will revolt if I remove their favorite tools A: Good senior developers care about shipping features, not playing with toys. Show them the DevEx improvement: one connection pool, one monitoring dashboard, one backup strategy. If they still complain, they’re not as senior as they think. Real developers want to solve hairy feature challenges, not play with more toys.

Q: This sounds like technical debt waiting to happen A: Technical debt is having six different query languages, four different monitoring tools, and three different backup strategies. Postgres for everything is technical credit—you’re investing in simplicity that pays dividends later.

Q: How do I sell this to investors/board members? A: “We reduced our operational overhead by 60% and increased feature delivery speed by 50%.” They don’t care about your tech stack. They care about results.

About the Author

Stephan Schmidt is a seasoned CTO and technology leader with over 40 years of experience building and scaling software systems. As a former CTO of multiple startups and scale-ups, he has firsthand experience with the operational complexity that comes from managing multiple database technologies.

Stephan has successfully guided engineering teams through technology simplification initiatives, reducing operational overhead while improving developer productivity. His approach of “Postgres for everything” has been battle-tested across various industries and company sizes, from early-stage startups to companies serving millions of users.

Currently providing CTO coaching to technology leaders worldwide, Stephan helps CTOs make pragmatic technology decisions that prioritize business outcomes over technical complexity.