Postgres as the 'everything store': a pragmatic founder's guide

An analysis of the perennial debate: use Postgres for queues, search, and more, or adopt specialized systems? We synthesize the trade-offs for early-stage teams based on founder discussions.

The Answer Up Front

For most early-stage teams, the answer is yes, you should start by using Postgres for more than just your primary data store. This approach is for founders who prioritize development speed and operational simplicity over at-scale performance. The ability to manage one system for your database, cache, and job queue is a significant advantage when engineering resources are scarce. You should skip this approach if your core product is a high-throughput data pipeline, a real-time analytics engine, or a search-heavy application where specialized systems are a day-one requirement. The bottom line: use Postgres for everything until you have a monitoring dashboard with a specific, undeniable bottleneck that a dedicated tool would solve.

Methodology

This is a v0 review based on a synthesis of community discussion, not a controlled benchmark. It analyzes the arguments and anecdotal experiences shared in a public Hacker News thread titled "Do you need separate systems when you already have Postgres?" on July 7, 2026. The source material represents collective wisdom and real-world trade-offs faced by founders and engineers, but does not contain reproducible performance figures. All performance characteristics mentioned are based on community claims, not independent testing.

This review covers:

• Common patterns for using Postgres as a job queue and search index.
• Frequently recommended extensions that expand Postgres's capabilities.
• The qualitative trade-offs between a consolidated and a specialized systems architecture.

This review does not cover:

• Quantitative performance benchmarks comparing Postgres to tools like RabbitMQ, Elasticsearch, or Redis.
• At-scale failure modes or detailed tuning guides for high-load scenarios.

An update is planned once we conduct independent benchmarks on these patterns.

What It Does

The "Postgres for everything" philosophy involves using the database's built-in features and rich extension ecosystem to handle tasks typically offloaded to other services.

Postgres as a job queue

Instead of setting up a separate service like RabbitMQ or Redis, teams can implement a reliable job queue directly in a Postgres table. The key is the SELECT ... FOR UPDATE SKIP LOCKED command. This allows multiple workers to pull jobs from the table concurrently without processing the same job twice. It's a simple, transactionally safe way to manage background tasks. Combined with NOTIFY/LISTEN, you can build a responsive system where workers are alerted to new jobs immediately, avoiding constant polling of the database.

Full-text search inside the database

For many applications, a dedicated search server like Elasticsearch is overkill. Postgres has robust built-in full-text search (FTS) capabilities using tsvector and tsquery types. It supports stemming, ranking, and multiple languages. For more advanced fuzzy or prefix searching, the pg_trgm extension provides trigram-based matching, which is often sufficient for features like autocomplete or handling user typos without the operational overhead of another service.

Beyond queues and search: extensions

The true power of this approach lies in the extension ecosystem. Tools like pg_cron allow you to schedule SQL commands directly within the database, replacing external cron jobs. TimescaleDB transforms Postgres into a powerful time-series database, competitive with InfluxDB for many use cases. For geospatial data, PostGIS is the industry standard. These extensions are not hacks; they are mature, production-ready additions that turn a general-purpose database into a specialized tool without adding a new server to manage.

What's Interesting / What's Not

The most compelling argument for this approach is radical operational simplicity. A single system to learn, manage, back up, and monitor reduces both cognitive load and infrastructure costs. The transactional guarantees are a significant, often overlooked, benefit. You can dequeue a job and update application state in a single atomic transaction, which eliminates a whole class of consistency problems that are complex to solve in a distributed system.

The trade-offs are real and should not be ignored. This approach has a clear performance ceiling. A dedicated tool like Kafka will always outperform a Postgres-based queue for high-throughput event streaming. Elasticsearch offers far more advanced search features, analytics, and scalability than Postgres's built-in FTS. You are also creating a single point of failure. If your database experiences high load or downtime, it can cascade and take down your queueing, search, and caching functionality simultaneously. Tuning a single database serving many different access patterns can become a specialized skill in itself.

Pricing

PostgreSQL is free, open-source software. Costs are associated with hosting and management, which vary by provider (e.g., self-hosted, AWS RDS, Neon, Supabase, Crunchy Data). There are no licensing fees for the database or popular extensions like PostGIS, pg_cron, or pg_trgm. Pricing snapshot: July 7, 2026.

Verdict

For a startup or a new project, starting with a consolidated Postgres architecture is the correct default choice. The engineering cost of premature optimization and managing a complex, multi-system architecture is often far higher than the cost of hitting a performance wall with Postgres and then migrating a specific workload. The key is to instrument your application properly. Monitor query latencies, queue depth, and search performance. When a clear, persistent bottleneck appears that cannot be solved with standard database tuning (e.g., adding an index), that is the time to evaluate a dedicated service. Until then, the simplicity and transactional safety of keeping it all in Postgres will let you ship faster.

What We'd Test Next

To move this analysis from claims to verified behavior, a v2 review would require a series of benchmarks. First, we would test queue throughput, comparing a SKIP LOCKED implementation in Postgres against SQS and RabbitMQ under various load profiles and job sizes. Second, we would evaluate search performance and relevance, indexing a 10-million-document dataset in both Postgres (with FTS and pg_trgm) and a comparable Meilisearch instance. Finally, we would measure the impact of heavy background job processing on the p99 latency of primary application queries to understand the resource contention in a real-world scenario.

The investor read

The 'Postgres for everything' pattern signals a durable trend toward infrastructure consolidation, particularly for early and growth-stage companies. It's a direct reaction to the operational complexity and cost of the sprawling 'modern data stack.' This creates opportunities for companies that productize this simplicity. Managed Postgres providers like Supabase, Neon, and Tembo are investable because they offer a 'batteries-included' experience that directly serves this need. For investors evaluating startups, seeing a team thoughtfully use Postgres for multiple functions is a positive signal of capital efficiency and focus on product over infrastructure. The key risk to underwrite is whether the team has the monitoring and expertise to recognize when they are out-scaling the consolidated model and can execute a migration without disrupting the business.