TL;DR — One Postgres database serves almost every SaaS workload through small-to-mid scale: relational, JSON documents, vectors, full-text search and queues. Reach for a specialized store only when one workload outgrows Postgres on its own axis.
The “use the right tool” advice has a quiet cost: every additional database is another thing to operate, monitor, back up and reason about. Most teams collect tools before they need them. Our default — and what we recommend for nearly every new SaaS — is one Postgres instance that does almost everything until it visibly cannot.
What Postgres covers well in 2026
- Relational data — obviously
- JSON documents via JSONB with GIN indexes
- Vector similarity search via pgvector with HNSW indexes, comfortable through ~5M embeddings
- Full-text search via tsvector + ts_rank, enough for most product search until you need typo-tolerance
- Queues via SKIP LOCKED — boring, transactional, no separate infrastructure
- Time-windowed aggregates via materialized views refreshed nightly
Where Postgres stops being the right tool
- Vector search past ~10M rows — move to Qdrant or Pinecone (see comparison)
- Time-series at high write rates — TimescaleDB extension is the first move; ClickHouse if planning costs dominate
- Multi-region active-active — Postgres is async-replica friendly, but conflict-free multi-region writes need different architecture
- Search with fuzzy matching and ranking complexity — Meilisearch or Typesense win on UX
The pattern we ship
- One Postgres for the product, plus a read replica for reporting
- JSONB for anything that does not yet have a stable schema
- pgvector for embeddings until proven inadequate
- SKIP LOCKED queues for background jobs, not Redis or RabbitMQ
- Materialized views for hot aggregations, refreshed nightly
- Add a specialized store only after a Postgres benchmark fails the SLO
This default is not exciting. It is operationally cheap, scales further than most products need, and means the team can focus on the product instead of the platform.
Frequently asked questions
Should every SaaS start with Postgres?
Yes, for almost every product. Postgres covers relational, document (JSONB), vector (pgvector), full-text and queue workloads adequately at small-to-mid scale. Specialized stores buy speed but cost operational complexity.
When do we add a second database?
When a single workload outgrows Postgres on its own dimension: vector search past ~10M rows, time-series past ~10k inserts/sec, or analytics where Postgres planning costs dominate.
Working on something similar?
T-Square architects, builds and operates production systems for learning, AI and custom software products. Talk to a senior engineer for a second opinion.