Understanding Embeddings in PostgreSQL

Embeddings have become one of the fundamental building blocks of modern AI systems.

Whether we are building semantic search, recommendation systems, RAG applications, multimodal search, or intelligent agent routing, the basic idea is similar: convert information into a numerical representation that allows us to compare relationships mathematically.

PostgreSQL becomes particularly interesting here because extensions such as pgvector allow us to store vector representations alongside our regular relational data.

That means instead of introducing a completely separate vector database, we can keep something like:

Business data
+
Metadata
+
Permissions
+
Embeddings

inside the same PostgreSQL ecosystem.

One important distinction, however, is that PostgreSQL does not usually create the embedding. A model or algorithm creates the representation, while PostgreSQL stores it and helps us efficiently retrieve similar vectors.

The interesting question then becomes:

What kind of embedding should we use for a particular problem?

There isn't one universal embedding that works best everywhere.

Let's look at some of the major categories.

1. Dense Embeddings

Dense embeddings are probably what most of us think about when we hear the word embedding.

A dense embedding represents an object using a fixed-length numerical vector where most dimensions contain meaningful floating-point values.

For example:

Document
   ↓
Embedding model
   ↓
[0.12, -0.32, 0.81, 0.04, ...]

Models such as Word2Vec, GloVe and transformer-based embedding models produce this kind of representation.

Where do we use them?

Dense vectors are particularly useful when we care about semantic similarity.

Common examples include:

semantic document search
Retrieval-Augmented Generation
FAQ matching
recommendation systems
clustering similar content
matching user questions with relevant knowledge

A basic PostgreSQL representation might look like:

CREATE TABLE documents (
    id BIGSERIAL PRIMARY KEY,
    content TEXT NOT NULL,
    embedding VECTOR(768)
);

We could then retrieve the nearest vectors using cosine or another supported distance metric.

Conceptually:

"What cars were sold last month?"
        ↓
Query embedding
        ↓
Compare against document embeddings
        ↓
Most semantically similar documents

For most text-oriented AI applications, dense embeddings are usually the first option we evaluate.

2. Sparse Embeddings

Sparse embeddings take a different approach.

Instead of every dimension carrying a value, most dimensions are zero and only a relatively small number contain meaningful values.

Traditional examples include:

TF-IDF
bag-of-words representations
one-hot encoded features

Imagine a vocabulary containing 100,000 terms.

A particular document might only contain a few hundred of them.

Its representation therefore looks conceptually like:

[0, 0, 0.8, 0, 0, 0, 0.3, 0, ...]

Most dimensions are empty.

When are sparse representations useful?

They work particularly well when exact terms matter.

For example:

VIN
product code
employee ID
technical keyword
legal clause number
specific model name

Dense semantic embeddings may sometimes generalize too much.

Sparse representations retain strong lexical signals.

This is why modern search platforms often combine:

Dense semantic retrieval
        +
Sparse lexical retrieval
        ↓
Hybrid search

Hybrid retrieval can give us the best of both worlds.

3. Binary Embeddings

Binary embeddings compress information into values such as:

0 1 1 0 0 1 0 1 ...

rather than storing full floating-point numbers.

Why would we want that?

Consider an embedding with thousands of dimensions across tens or hundreds of millions of records.

Storage and similarity computation can become significant.

Binary representations trade some precision for:

lower storage
faster comparison
efficient approximate search

A binary representation is particularly attractive when extremely large-scale nearest-neighbour retrieval matters more than perfect ranking accuracy.

Typical use cases include:

large visual-search systems
approximate nearest-neighbour retrieval
deduplication
high-volume similarity systems

The principle is essentially:

Full precision embedding

[0.134, -0.55, 0.87, ...]

        ↓ quantization

[1, 0, 1, ...]

The resulting representation is considerably smaller.

4. Hierarchical Embeddings

Not all information lives in a flat space.

Consider an organization:

Company
 ├── Commercial
 │    ├── Sales
 │    └── Pricing
 │
 └── People
      ├── HR
      └── Recruitment

Or a product taxonomy:

Vehicle
   ↓
Passenger Vehicle
   ↓
SUV
   ↓
Electric SUV

Hierarchical embeddings try to preserve those kinds of relationships.

Instead of merely asking:

Are A and B semantically similar?

we may also want to understand:

Where do A and B sit within a hierarchy?

Potential applications include:

organizational structures
product catalogs
knowledge taxonomies
category classification
hierarchical recommendations

For example, a search for:

Electric SUVs

should naturally connect to:

SUV
Vehicle
Passenger Vehicle
EV

without treating all concepts as unrelated flat vectors.

The original article groups hierarchical embeddings separately for exactly these kinds of structured relationships.

5. Multimodal Embeddings

Things become even more interesting when our data isn't only text.

Imagine an e-commerce system containing:

Product description
Product image
Customer review
Video
Audio

We may want to search all of them together.

Multimodal embedding models create representations where different modalities can occupy compatible embedding spaces.

A well-known example is CLIP-style text/image representations.

This makes queries such as:

"red sports car"

capable of retrieving an image even when the phrase doesn't literally appear in its metadata.

Conceptually:

Text ───────┐
            │
Image ──────┼──→ Shared embedding space
            │
Video ──────┘

Applications include:

visual product search
media libraries
document + image retrieval
multimodal RAG
cross-modal recommendations

A PostgreSQL table might simply keep the resulting representation:

CREATE TABLE media (
    id BIGSERIAL PRIMARY KEY,
    media_type TEXT,
    source_url TEXT,
    embedding VECTOR(512)
);

The model producing those vectors determines whether the modalities are actually comparable.

6. Time-Series Embeddings

Time-series data has another special characteristic:

order matters.

Consider:

Jan → Feb → Mar → Apr → May

Rearranging those points destroys information.

Models designed for time-series data therefore try to capture things such as:

trends
periodicity
seasonality
temporal dependencies
anomalies

Examples of techniques include:

autoencoder-based representations
recurrent models
Time2Vec-style representations

Potential use cases include:

Anomaly detection

Instead of comparing individual values:

we compare patterns.

Forecasting

Historical windows can be encoded and compared against previous patterns.

Operational monitoring

Similar incidents can potentially be retrieved based on the shape of telemetry rather than only exact values.

The resulting vectors can again be stored and searched from PostgreSQL.

7. Graph Embeddings

Graph embeddings become particularly interesting when the relationships themselves contain valuable information.

Imagine this graph:

                 pricing
                    │
                    │
       ┌────────────┴───────────┐
       │                        │
Pricing Agent              Vehicle Domain
       │
     market
       │
 Europe

A normal text embedding primarily captures what each piece of text means.

A graph embedding can additionally capture:

How nodes are connected.

Examples include:

Node2Vec
GraphSAGE

Graph embeddings can represent:

nodes
edges
neighborhoods
network structure

and therefore become useful for problems such as:

social-network analysis
recommendation systems
fraud networks
knowledge graphs
dependency analysis
organizational relationships

Conclusion

There is no universally “best” embedding.

The right representation depends on what information we are trying to preserve.

Dense embeddings preserve semantic meaning.

Sparse representations preserve strong lexical signals.

Binary representations optimize storage and computation.

Hierarchical representations capture taxonomies.

Multimodal embeddings connect different media types.

Time-series embeddings preserve temporal patterns.

And graph embeddings capture relationships between things.

PostgreSQL gives us an interesting foundation because these vector representations can live next to our existing operational data, metadata, permissions and business rules.

The bigger architectural opportunity is therefore not simply:

How do we store embeddings?

It is:

How do we combine embeddings, structured data, graph relationships and business constraints to retrieve the right information—or the right agents—before the expensive AI reasoning begins?

That is where PostgreSQL and pgvector can become much more than just another vector database.

Understanding Embeddings in PostgreSQL: Which Type Should We Use and When?