When does a workload earn its own system?

Three shapes of answer

Everything built on top of ordinary storage assumes that a predicate reduces to a range over a total order, or to an equality under a hash. This mechanism is the catalogue of what you build when that reduction is unavailable. The answers fall into three shapes.

Shape	Families	When it is used	How it works and what it costs
1. Project to something prunable, and refine	Text, vector, spatial	A lossy mapping with a one-sided guarantee exists. This is this mechanism's default answer.	Map each object to a cheap form, drop candidates with no false negatives, verify the survivors.
2. Change the execution model	Graph	No such mapping exists, because reachability has no bound.	Batch by round instead of by address. The price is a barrier (a wait for all workers) per hop.
3. Specialize the representation	Time series	The predicate was never the problem; the redundancy was.	Encodings and rollups tuned to the data.

The recurring arithmetic

Every family has one binding resource, one knob that trades it, and one currency in which the trade is paid.

Family	Binding resource	The knob	Paid in
Text	postings scanned	early-termination threshold	index size; freshness versus segment count
Vector	memory bandwidth	recall (`nprobe` / `efSearch` / bits per vector)	recall; rebuild cost
Graph	coordination per hop	traversal depth; active-set shrinkage	barriers, stragglers, hub replication
Geospatial	refine-stage work	cell resolution / fill ratio	duplication or multi-path search
Time series	series count; bytes per point	rollup resolution; retention tier	irreversible loss of future questions

Every family hides a power-law distribution: Zipfian terms in text, power-law vertex degree in graphs, clustered spatial density in maps, hot series labels in metrics. So variance, not volume, sets each one's worst case.

Specialized versus general engines

"Specialized engines always beat general ones for these workloads" is currently true and eroding, not permanent. It is an economic claim about where engineering effort has been spent. The gap narrows each time a general columnar engine absorbs an encoding or an index type. So "should this be a separate system?" is a cost question with a moving answer. The cost is only moved: a separate system relocates the cost from query speed into operations, and a general engine relocates it the other way.

What a new system costs beyond its engine

A few costs belong to no single family. They apply to every one of them.

The specialization decision is a pipeline decision, not just an engine decision. Each family implies a whole ingestion path:

embeddings need a model-inference stage;
search needs text analysis;
a graph needs edge construction from relational sources;
time series needs a collection agent.

Adopting one of these means committing to a second write path with its own freshness, its own failure modes and its own reconciliation problem against the source of truth. And a second computation with no shared substrate can never be verified against the first, only reconciled. The engine is the cheap part.

Every family here is a derived dataset, and none of them owns its data. Search indexes, vector indexes, graph projections and rollups are all views over records that live somewhere else. So each inherits the full set of derived-data problems: how changes propagate, how you backfill, how you rebuild after a bug, how you know the copy is current. Text and vector indexes rebuild from scratch, and it takes hours to days. That rebuild time is the real recovery-time objective (how long until the feature works again after losing the index) of the feature, and it is rarely measured.

Deletion propagation is a shared, unsolved problem. A record deleted at the source must disappear from the inverted index, the vector index, every rollup and every graph projection. Some of those structures tombstone and only truly delete at rebuild. Some cannot delete at all without invalidating what they were fitted to. Privacy rules (the right to be forgotten) collide with this whole mechanism at once, and the collision has no clean general answer.

Nothing here composes. A query that is at once semantic, filtered, geographic and time-bounded has to be answered by one of these structures, with the rest applied as post-filters. Post-filtering is exactly the strategy the vector article showed degrading as selectivity falls. Multi-modal predicates are where this mechanism's mechanisms actively obstruct each other, and no combined index serves all of them. This is unsettled, and it is best held as an open question and not as a gap.

Ranking quality and system quality are separate variables that people conflate. Recall against brute force, relevance against human judgement, and business outcome are three different measurements. Improving the first has no guaranteed effect on the third. Most tuning effort here goes into the one that is easiest to measure.

Closing

This mechanism's claim, in one line:

Three escape shapes, and every family is one of them: project-and-refine (text, vector, spatial), change the execution model (graph), specialize the representation (time series).

Two rules from the families are worth carrying into everything built on top of this mechanism:

The algebra rule, because it predicts, before you look at any implementation, whether something can be skipped, merged, pushed down or precomputed: is the function decomposable, does it have an upper bound, is it a metric?
The fitted-structure rule, because it is the common cause of every silent degradation, from filtered ANN to cardinality estimation to autoscaling: a structure fitted to yesterday's distribution does not complain when the distribution moves.

Two questions can be asked of any system, and they have unusually clean answers here. What does this mechanism assume that it cannot verify? That its derived copies are current, and that the data's distribution still resembles the one its structures were fitted to. Who pays when the assumption breaks? Not the system. It returns a plausible answer. The reader pays, silently, and usually much later.

Case, resolvedConstructed case · Elin at Haatly

Seven systems: when does the next one earn its place?

With PostgreSQL, a search cluster, a vector index, a graph engine, a geo index, a metrics store and a feature store, Elin asked how to decide when the next workload deserves its own system. Where it started: What specialization adds →

Amara answers Elin with a one-page checklist, built from this article:

Can the predicate become a range or an equality? If yes, use the general engine. PostgreSQL already does this well.
If not, which of the three shapes applies? Project-and-refine (is there a one-sided mapping?), change the execution model (is it reachability?), or specialize the representation (is the data redundant but the predicate easy?).
Name the binding resource and the knob. Postings scanned, memory bandwidth, coordination per hop, refine work, or series count. Decide who owns the knob.
Price the pipeline, not only the engine. A second write path, a freshness metric, a reconciliation job, a deletion path, and a rebuild time that is measured.
Ask whether a general engine is close enough. If an extension to PostgreSQL gets within the budget, the cost of a second system may exceed its benefit. That line moves every year.
Say what you cannot verify, and who finds out first.

Elin reads it and replies: "So the question is not whether the new system is faster. It is what we have promised to keep true, and for how long." Amara nods. That sentence goes at the top of the page.