Build 1 publisher2 min readPublished September 17, 2026 at 4:07 AM PDT

JSONB and pgvector cover two of the five roles this Postgres consolidation absorbs

A dev.to design guide moves JSON documents and vector search into one PostgreSQL instance, and the evidence it offers is operational: deleted ETL pipelines and sync bugs, with no query timings on either side.

The Engineer · Build desk

Illustration accompanying JSONB and pgvector cover two of the five roles this Postgres consolidation absorbs

What happened

A dev.to design guide sets out how to run JSON documents, time-series data and vector similarity search inside one PostgreSQL instance, with the aim of eliminating multi-database sprawl.
Its account of the mid-2010s stack lists six categories, including MongoDB for documents, Redis for session state, Elasticsearch for log analytics and Pinecone or Qdrant for embeddings.
The charge it lays against that stack is that teams spent more time on cross-database synchronization, eventual consistency bugs, ETL pipelines, hosting costs and local dev setups than on shipping features.
Feature-flag lookups are written as JSONB containment matches, asking for rows whose settings contain a nested feature_flags object with beta_access set to true.
For vectors it enables pgvector and builds an HNSW index over cosine distance with m set to 16 and ef_construction set to 64.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

decision The consolidation call now rests on evidence each team has to gather locally: hours lost keeping two stores in step, weighed against the latency budget a specialised engine was bought to meet.
cost Copying the listing wholesale means adopting its HNSW build settings as production settings, and the instance serving transactions is the one paying for index builds and approximate scans.
capability Scoping a similarity search by tenant in the same statement removes the round trip a separate vector store needs, and the candidate IDs stay inside one system.
constraint Absorbing the vector role as an extension ties that workload to one Postgres version and one maintenance window shared with the relational data.

JSONB differs from a JSON text column at write time. Postgres decomposes the document into a binary format then, and that is what makes indexing and partial updates possible ^[6]. The listing puts two GIN indexes on the same column, one over the whole settings document and one over the feature_flags path inside it ^[8]. Updates go through jsonb_set, which changes a nested billing tier and leaves the rest of the document in place ^[10]. Before keeping both indexes in production I would want to know how often that column is written.

Vectors are the half I would test first. The embedding column is declared vector(1536), sized in a comment for OpenAI's text-embedding-3-small ^[13]. The search filters on tenant_id, orders by the cosine distance operator and takes five rows ^[15]. One equality predicate over a single tenant, one approximate index built across every tenant's rows: I would measure recall on that combination, at the build parameters the DDL supplies ^[14]. Whether the tenant predicate is applied before or after the approximate scan changes which five rows come back.

The performance claim is a single sentence. With GIN indexing, the article says, Postgres can query nested JSON fields "at speeds comparable to native document databases" ^[7]. The article publishes no measurement, for Postgres or for the document engine it is compared against ^[17]. To move that claim onto another workload you would need documents of a similar size, query shapes GIN can serve, an index that fits in memory and comparable write concurrency.

Count the categories in the stack the piece displaces and there are six. One of them is Postgres, which leaves five roles to move, and DDL with worked queries appears for two of them, documents and embeddings ^[18]. The time-series case opens on append-only metric streams such as telemetry, audit logs and financial tickers, and the text available stops there ^[16].

I would act on the operational claim first, because a team can price it from its own incident log ^[4], and the latency comparison needs a run on your own data before it counts for anything ^[7].

What to watch

Whether the guide's time-series section leans on stock Postgres partitioning or on the Timescale extension. That choice decides whether the consolidation stays on vanilla Postgres.
Whether recall figures appear for filtered HNSW search under tenant scoping at the build parameters the listing uses.
Whether the caching and full-text search roles from the article's own list get the same DDL treatment as documents and vectors.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[11]
The article says PostgreSQL supports vector indexing directly via the pgvector extension, instead of introducing a standalone vector database cluster and incurring extra network latency and data sync overhead.
ReportedSupported2 sources— sign in to open View cited source
[12]
The article says storing embeddings next to operational transactional records lets applications run relational SQL filters and semantic vector similarity in a single query pass.
ReportedSupported2 sources— sign in to open View cited source
[16]
The article's time-series section says handling massive append-only metric streams such as telemetry, audit logs or financial tickers requires efficient handling; the available text ends mid-sentence there.
ReportedSupported2 sources— sign in to open View cited source
[1]
A dev.to article, "Beyond Pure Relational SQL: Designing Hybrid Multi-Model Persistence with PostgreSQL", describes how engineering teams use PostgreSQL for JSON documents, time-series data and vector similarity to eliminate multi-database sprawl.
ReportedSupportedView cited source
[2]
The article says backend architecture in the mid-2010s followed a trend known as Polyglot Persistence, whose rule was to use a specialized database for every distinct data access pattern.
ReportedSupportedView cited source
[3]
The article lists a typical modern enterprise stack in six categories: PostgreSQL or MySQL for core relational ACID data; MongoDB or Couchbase for dynamic JSON document storage; Redis for high-throughput key-value caching and session state; Elasticsearch for full-text search and log analytics; TimescaleDB or InfluxDB for metric time-series streams; Pinecone or Qdrant for high-dimensional vector embeddings.
ReportedSupportedView cited source
[6]
The article says JSONB parses JSON into a decomposed binary format at write time, unlike raw JSON text columns, allowing fast execution, indexing and partial document updates.
ReportedSupportedView cited source
[8]
The article's DDL creates two GIN indexes on the same JSONB column: idx_accounts_settings_gin USING GIN (settings), and idx_accounts_feature_flags USING GIN ((settings -> 'feature_flags')).
ReportedSupportedView cited source
[9]
The article's example query selects accounts WHERE settings @> '{"feature_flags": {"beta_access": true}}', using the JSONB containment operator to match a nested object.
ReportedSupportedView cited source
[10]
The article's update example uses jsonb_set(settings, '{billing,tier}', '"enterprise"') and describes it as an atomic partial update of a nested JSON property without rewriting the whole document.
ReportedSupportedView cited source
[13]
The article's document_embeddings table declares a column embedding vector(1536), commented as the dimension size for OpenAI text-embedding-3-small.
ReportedSupportedView cited source
[14]
The article builds an HNSW index on the embedding column using hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64).
ReportedSupportedView cited source
[15]
The article's combined query selects from document_embeddings WHERE tenant_id = a given UUID, ORDER BY embedding <=> a query vector ASC, LIMIT 5, reporting similarity as 1 - (embedding <=> query vector).
ReportedSupportedView cited source
[17]
The available text of the article contains no benchmark figures, latency measurements or recall numbers for either the JSONB or the pgvector examples.
ReportedSupportedView cited source
[18]
Of the six database categories the article lists, one is PostgreSQL or MySQL itself, leaving five roles to absorb; the available text supplies DDL and worked queries for two of them, JSON documents and vector embeddings.
DerivedSupported2 sources— sign in to open
[4]
The article says engineering teams spent more time managing cross-database synchronization, eventual consistency bugs, ETL pipelines, multi-cloud hosting costs and complex local dev setups than shipping product features.
ReportedInsufficientView cited source
[7]
The article says that by applying GIN indexing, PostgreSQL can query nested JSON fields "at speeds comparable to native document databases".
ReportedInsufficientView cited source

Sources

Publishers with included, body-backed reporting in this cluster.

dev.to
1 article · September 17, 2026
Beyond Pure Relational SQL: Designing Hybrid Multi-Model Persistence with PostgreSQL

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

A builder can use this straight away. The JSONB half supplies two GIN indexes on one settings column, a containment read and a jsonb_set write against a nested key; the vector half supplies a 1536-dimension column for text-embedding-3-small, an HNSW index at m = 16 and ef_construction = 64, and a five-result similarity search filtered by tenant. The cost of those indexes is left out. A GIN index over the whole document is paid on every write to it, and HNSW build time and memory grow with the table.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence35

0100

Checkable DDL, unmeasured claims

Every SQL statement here can be pasted into a PostgreSQL shell and confirmed, and that is the solid part of the story. The claims that would actually decide a consolidation are of a different kind: speed comparable to a native document database, fast execution over billions of partitioned rows, 95% of applications simpler on one engine. Each is one author's assertion, and no second publisher carries the piece.

AdoptionInsufficient

Illustrative stack only

The six-category stack is a sketch the author draws to argue against, not a system anyone is named as running. There is no team, no data volume, no migration and no before-and-after, so nothing in this reporting measures how far the consolidation pattern has actually travelled.

Hype gap+30

−100 understated0 aligned+100 overstated

Sweeping where it is untested

The gap sits in two sentences a reader might act on: JSON queries "at speeds comparable to native document databases", and consolidation that "simplifies operations for 95% of software applications". Neither has a number behind it. What keeps the score from climbing is the author's own boundary list, which sends microsecond caching to Redis or Memcached, multi-billion-vector retrieval to dedicated or GPU hardware, and deep graph traversal to Neo4j or Amazon Neptune.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

build
Four control planes, one Postgres: a team's case against polyglot persistence
1 publisher
build
The query a vector index cannot answer, whatever you embed it with
1 publisher
build
Three services you can delete: queue, cache and search in one Postgres
1 publisher
build
DuckDB's vss extension removes a database from your RAG stack, then names the price
1 publisher

JSONB and pgvector cover two of the five roles this Postgres consolidation absorbs

What happened

Why it matters

What to watch

Claim ledger

Sources

Topics and entities

Topics

Entities

Claim ledger

Topics and entities

Topics

Entities

Perspective Coverage

Reality

Sources

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Perspective Coverage

Reality

Related stories

Sources