Postgres or a Specialised Database in 2026? Vectors, Queues, Time Series and Search

By Stackvora Team · 2026-08-29 · 8 min read

"Just use Postgres" became the default advice for a good reason: one database you operate well beats four you operate badly. But the advice has limits, and knowing where they are saves both premature complexity and painful late migrations.

Vector search

pgvector with HNSW indexing handles millions of embeddings comfortably on properly sized hardware, and it gives you something dedicated vector stores struggle with: joining vectors to relational data in a single transactional query. Filter by tenant, permission and date alongside similarity, with no synchronisation layer.

Move to a dedicated vector engine when you cross roughly tens of millions of vectors with strict low-latency requirements, need frequent full re-indexing without impacting OLTP, or require sharded horizontal scale. Before you do, check the cheaper fixes: reduce dimensions, quantise, and make sure the index actually fits in memory.

Job queues

A queue table with SELECT ... FOR UPDATE SKIP LOCKED is robust, transactional and easy to reason about. Enqueueing a job in the same transaction as the data change eliminates an entire class of consistency bug that external brokers create. It scales to thousands of jobs per second on ordinary hardware.

Reach for a dedicated broker when you need fan-out to many independent consumers, replay of historical streams, cross-datacentre delivery, or sustained throughput well beyond what a single primary can absorb alongside its normal write load. Long-lived job rows also cause bloat, so partition and prune aggressively if you stay in Postgres.

Time series

Native declarative partitioning plus BRIN indexes take plain Postgres a long way for metrics and event data. The pressure points are ingest rate and retention: high-frequency writes with years of history produce table counts and vacuum pressure that become an operational burden. Compression and continuous aggregates from a columnar or time-series extension usually solve it without leaving the ecosystem.

Full-text search

tsvector with a GIN index gives good, cheap search with real transactional consistency — no index-sync lag, no separate cluster. It is weaker on fuzzy matching, faceting, synonyms and relevance tuning. If product managers are asking for typo tolerance, weighted boosting and faceted filters, a search engine is the right tool; if they want "find the document with these words", Postgres already does it.

The real cost of adding a system

Every additional datastore adds backups, monitoring, upgrades, access control, an on-call runbook, and a consistency boundary where data can silently drift. That cost is fixed and permanent, while the performance benefit is often specific to one feature. Quantify both before adding one.

A decision rule

Stay on Postgres while you can state, with numbers, that it is meeting your latency and throughput targets at projected growth. Move a workload out when you have measured it failing those targets after tuning — not when a benchmark blog post suggests you might.

Key takeaways

• pgvector plus relational filtering beats a separate vector store for most applications.
• SKIP LOCKED queues give transactional enqueue and are enough for most systems.
• Partitioning and BRIN cover a lot of time-series ground before a specialist is needed.
• Full-text search in Postgres is fine until relevance tuning becomes a product requirement.
• Every extra datastore is permanent operational cost — justify it with measurements.

Weighing a specific workload? Describe your query patterns to Stackvora AI, or read the PostgreSQL guides in the knowledge base.