Do you need a separate vector database?

OriginChainDB Team · May 5, 2026

architecture vector-database design ai-native

TL;DR - A separate vector database is the wrong shape for AI-native applications. Vectors describe entities; entities have schemas, lifecycles, and consistency needs. Splitting them across two systems creates dual-write bugs, replication lag, and operational overhead with nothing to show for it. We argue the correct architecture is one substrate, multiple shapes - and that this is the entire premise of OriginChainDB.

What a “vector database” actually is

A vector database stores high-dimensional vectors and supports approximate nearest-neighbor (ANN) search over them. Most also support filtering on metadata attached to each vector. Pinecone, Weaviate, Milvus, Chroma, Qdrant - they’re all variations on this theme.

The thing they have in common: they assume the rest of your data lives somewhere else. The vector is a sidecar to a “real” record that’s stored in Postgres, Mongo, DynamoDB, or wherever your application’s source of truth lives. You generate the embedding from the real record, push it to the vector DB, and rely on a stream or worker to keep the two in sync.

This is the architecture we think is wrong.

What it costs you

Dual-write bugs. Every team running this architecture eventually debugs a “why isn’t this record in search results?” report. The entity was written to the primary DB, but the embedding generation failed (or was retried, or the vector DB rate-limited). Some window of writes are visible in the primary but invisible to ANN search. You can mitigate this with idempotent workers, dead-letter queues, and reconciliation jobs - but you can’t eliminate it without atomic writes across both systems, which the architecture rules out by definition.

Operational duplication. Two systems means two backup strategies, two failover plans, two monitoring dashboards, two on-call rotations (or one rotation responsible for two), two cost models. Each system has its own scaling story you have to learn.

Schema drift. The vector DB has its own metadata schema. Adding a field to your entity that you want to filter ANN results on is two operations: update the entity schema, then update the vector DB metadata schema. They must be kept consistent forever. They drift.

Cost duplication. You’re paying to store the same identifying information twice - once on the entity in the primary DB, once as metadata on the vector. At small scale this is invisible; at hundreds of millions of records it’s not.

What the alternative looks like

We model vectors as just another shape in the substrate.

- shape: article
 key: "article/{id}"
 value: { title: string, body: string, author: string }

- shape: article-embedding
 key: "vec/article/{id}/body"
 value: { type: f32, dim: 768 }

Two shapes. One substrate. One atomic write.

When you write an article, you write its embedding in the same transaction:

await oc.transaction([
 { shape: "article", id, set: { title, body, author } },
 { shape: "article-embedding", id, set: embedding },
]);

Both writes commit in a single atomic operation. The article is never visible to a regular read without the vector being visible to ANN search, and vice versa. There is no replication lag because there is no replica.

When you ANN-search, you get back ids; you hydrate them with a parallel batch read against the entity shape. One round-trip from the client, two reads inside the substrate.

”But isn’t a specialty engine faster?”

This is the standard objection. Specialty vector databases tune their ANN engines harder than a general-purpose substrate would. Surely they’re faster.

The answer is: yes, at very large scale (>100M vectors with high QPS), and no, anywhere else. We measure ANN search at sub-millisecond p50 on corpuses up to ~10M vectors. Past that, the gap to a dedicated engine starts to widen, and the depth-first optimiser work on our roadmap is what closes it.

The teams running into the “vector DB is faster” wall are usually past 100M vectors. Most teams aren’t there. And even at that scale, the cost of running two systems is rarely paid for by the marginal latency improvement on the search call.

”But what about graph queries / full-text / time-series?”

Same argument. Each of these is a “specialty engine” in the same sense a vector DB is. The right architecture isn’t to bolt them on as separate services - it’s to model them as shapes in one substrate.

We’re not there for graph or FTS yet (those are post-1.0; see the roadmap). The principle stands: one substrate, multiple shapes.

When the separate-vector-DB model still wins

Honest answer: when your primary database is non-negotiable and your vectors are an add-on feature you’re prototyping. If you have a 10-year-old Postgres deployment, established team workflows, and a small AI feature being trialed on the side, adding Pinecone is the lowest-disruption path. The architecture is wrong, but the migration cost would be wronger.

If you’re greenfield, or your AI feature is core to the product, or you’re already feeling the dual-write pain - that’s when one substrate becomes the right answer.

FAQ

What is a vector database?

A vector database stores high-dimensional vectors (typically embeddings from ML models) and supports approximate nearest-neighbor search over them. Most also support metadata filtering. Examples: Pinecone, Weaviate, Milvus, Qdrant, Chroma.

Why is a separate vector database the wrong architecture for AI-native apps?

Because it requires dual-writing the entity (in your primary DB) and its embedding (in the vector DB). This creates eventual-consistency windows, operational duplication, and schema drift between the two systems. AI-native applications produce so many writes per session that these costs compound quickly.

Doesn’t OriginChainDB just contain a vector engine?

Yes - but the engine reads from the same substrate as every other shape. The substrate is unified; the vector engine is a query path, not a separate system.

Is the unified-substrate model novel?

The principle isn’t novel - Postgres + pgvector is the same idea. What’s novel is doing it from a managed K/V substrate purpose-built for AI workloads, with the throughput and atomic-multi-shape characteristics that follow.

Can I keep using a separate vector DB if I want?

Of course. OriginChainDB isn’t trying to take over your stack - it’s an alternative to the dual-write architecture. If your team is happy with the separate-vector-DB model, stay there.