Vicedomini Softworks

AI & Automation

Vector Databases for Italian Engineers: When PostgreSQL Is Enough

18 October 2026

Vector Databases for Italian Engineers: When PostgreSQL Is Enough

A vector database stores embeddings, numeric vectors that represent text, images or audio, and retrieves items by meaning rather than by exact keyword match. That is why teams add one when they build semantic search, retrieval-augmented generation (RAG) for large language models, or recommendation features. If your application needs to answer “what is similar to this?” rather than “what equals this?”, a vector database is the right tool.

TL;DR:

  • Embed every query with the same model used for its documents; vectors from different models occupy incompatible spaces and cannot be compared.
  • Match the distance metric to the embedding model’s training objective, then tune approximate search by measuring recall against latency on real queries.
  • Start with pgvector if PostgreSQL already serves your application; consider a distributed engine near 50 million vectors or when concurrency and memory demands rise.
  • For document ingestion, tune chunk size against context and match quality, replace vectors when source content changes, and remove deleted records from the index.
  • Treat embeddings as sensitive data and enforce access labels in every retrieval query; filtering only after results return can expose restricted documents.
Vicedomini Softworks
Choose the Right Vector Architecture
Vicedomini Softworks engineers custom software and integrations, helping teams assess how vector search fits their existing data infrastructure.
Ask for a consultation

Table of Contents

1. What data does a vector database store?

A vector database stores information as vectors, numeric arrays in which each vector corresponds to an object such as a word, an image, a video or a document. The vector expresses the position of that object in a high-dimensional space, and objects that share meaning or features end up close together.

In practice, a vector rarely travels alone. Production systems typically keep three kinds of data side by side:

  • The vector itself: the array of floating-point numbers produced by an embedding model.
  • Metadata: identifiers, timestamps, tags, language, tenant or access labels, used to filter results before or after the similarity search.
  • A pointer to the payload: a primary key or URL that lets the application fetch the original document, image or record once retrieval has identified the best matches.

Some engines also store the payload inline, which is convenient for small collections. Larger systems keep the canonical content in object storage or a relational database and store only the reference.

Dimensionality drives cost. The length of an embedding depends on the model that produced it, and every extra dimension multiplies memory and index size across the whole collection. A model that emits longer vectors may capture finer distinctions, but you pay for it in storage, RAM and query latency. Time-aware data is also supported: vector databases can manage timestamps and event sequences, which helps in anomaly detection and other time-sensitive analytics.

2. How are embeddings created, and what do they encode?

Embeddings come from machine-learning models, not from the database. Transformer-based text encoders turn sentences into vectors, while image models such as CLIP map pictures, and in some cases text, into a shared space. Whatever the model, the output is a fixed-length numeric vector for each input item.

What the vector encodes is relational. Two product descriptions that say the same thing in different words land near each other, whereas a description of something unrelated lands far away. Closeness in the embedding space is therefore a proxy for shared meaning or shared visual and acoustic features. The Fastly overview lists models such as Word2Vec, BERT and CLIP as typical sources of these vectors for unstructured data.

Three practical choices shape your pipeline:

  • Pre-trained models: the fastest route to a working prototype, and often good enough for general-purpose text.
  • Fine-tuning on domain data: worthwhile when your vocabulary is specialised, for example legal clauses, engineering tickets or product catalogues.
  • Dimensionality versus cost: shorter vectors are cheaper and faster, longer ones may separate near neighbours more cleanly. Measure on your own queries before committing.

One constraint is easy to overlook: you must embed queries with the same model that embedded the documents. Vectors from different models live in different spaces and cannot be compared.

Pro Tip: Freeze the embedding model name and version in your configuration and store it next to each vector, so a future model upgrade becomes a controlled re-indexing job instead of a silent quality regression.

3. How do similarity search and ANN work?

Retrieval starts by embedding the query and then asking the database for the vectors closest to it. “Closest” depends on the distance metric, and three are common:

  • Cosine similarity: compares the angle between two vectors and ignores their length, which makes it a natural default for text embeddings.
  • L2 (Euclidean) distance: measures the straight-line distance between points, so it is sensitive to magnitude as well as direction.
  • Inner product: rewards vectors that point the same way and are large, and is often used when the model was trained with that objective.

Match the metric to the one your embedding model was trained for. The wrong choice degrades relevance without raising any error.

Exact nearest-neighbour search compares the query with every stored vector. That is perfectly accurate and can work well for smaller collections, but it becomes too slow as collections grow. This is where Approximate Nearest Neighbour (ANN) algorithms come in: vector databases commonly use ANN algorithms for fast nearest-neighbour queries, accepting that the true best match may occasionally be missed.

The trade-off is described by recall, the share of true nearest neighbours that the approximate search actually returns, against latency. Most engines expose parameters that let you move along that curve: search more of the index and recall rises, latency rises with it. For most retrieval features, such as RAG context or “similar items”, a slightly imperfect set of results returned quickly can be more useful than a perfect set returned slowly.

4. Which indexing techniques matter: HNSW, IVF and PQ?

The index is the structure that makes ANN fast. Three families cover most of what you will meet:

  • HNSW (Hierarchical Navigable Small World): a layered graph in which a query hops from coarse to fine neighbourhoods. It offers high recall and low latency on small to medium collections, at the price of holding the graph in memory.
  • IVF (inverted file index): partitions the space into clusters and searches only the clusters nearest the query. It scales well and has a tunable recall setting, namely how many clusters you probe.
  • PQ (product quantisation): compresses each vector into a short code, cutting memory dramatically at the cost of some precision. It is frequently combined with IVF for very large collections.

Variants combine these ideas. For example, IVF with PQ trades accuracy for footprint, while HNSW can sit on top of compressed vectors to reduce memory.

When collections reach billions of vectors, RAM-only indexes become uneconomical. Disk-based indexes and hybrid strategies, with compressed vectors in memory and full-precision vectors on SSD, keep storage and query costs under control. The implication is architectural: index choice is a budget decision as much as a relevance decision, so model the memory footprint at your target scale before you pick one.

5. How does a vector database compare with a relational database?

Relational databases remain unbeatable at structured data, transactions, constraints and joins. Vector databases do something different: they retrieve unstructured content by semantic proximity. The two are complements, not rivals, and the useful question is how to combine them.

Three patterns recur:

  • Split storage: canonical records live in SQL, embeddings live in a dedicated vector store, and a shared identifier links them. This is clean, but you must keep the two in sync.
  • Extension in the relational engine: a vector type added to the SQL database, so rows and embeddings sit together and a single query can filter by metadata and rank by similarity.
  • Dedicated engine at the centre: the vector store holds embeddings plus enough metadata for filtering, and the relational database stays the system of record.

The operational trade-off is simplicity against scale. According to practitioner guidance comparing Milvus and pgvector, pgvector is a pragmatic first step for teams already on PostgreSQL because it avoids the complexity of running a separate distributed system. Purpose-built systems such as Milvus become the recommended choice when datasets grow to tens of millions of vectors or demand distributed, billion-scale architectures.

If you are searching for “pgvector vs Milvus”, this is the real answer: it is rarely about which product is better in the abstract, and almost always about how large your collection will be, how many concurrent queries you must serve, and how much operational surface your team can carry.

6. Which AI use cases rely on vector databases?

The technology maps onto a short list of concrete projects:

  1. Semantic search and RAG: the query is embedded, the closest passages are retrieved, and a language model answers using that context. This is the dominant driver of adoption today, and Italian-language coverage by ZeroUno highlights RAG and natural language processing as central use cases.
  2. Recommendation engines: users and items share an embedding space, so “people who liked this” becomes a nearest-neighbour query. The same approach drives personalised content discovery in music apps, e-commerce and social networks.
  3. Multimodal search: a text description retrieves matching images or video frames, because a model like CLIP places both in one space.
  4. Anomaly and fraud detection: records that sit far from every cluster of normal behaviour deserve attention, and, as noted earlier, time-aware data can be included in the analysis.

A practical use-case roundup from lakeFS adds image recognition and improving machine-learning models to the list. Whatever the project, the pattern is constant: embed, store, retrieve by proximity.

7. When should you use a lightweight extension, and when a dedicated engine?

Start from four signals: the expected number of vectors, query concurrency, embedding dimensionality, and your latency target in milliseconds. Small collections with modest traffic fit comfortably inside an existing database.

  • Start with a PostgreSQL extension when you already run PostgreSQL, the collection is modest, and you want one backup, one access-control model and one set of operational skills.
  • Plan for a distributed engine as you approach the scale practitioners commonly cite, around 50 million vectors, or when concurrency is high, or when embeddings are so long that they exceed PostgreSQL page limits.
  • Check production basics early: backups, monitoring, replication, cost per query and integration with your deployment pipeline matter as much as raw speed.

Pro Tip: Keep embeddings and their source identifiers in a model-agnostic schema from day one, so migrating from an extension to a dedicated engine is a data export, not a redesign.

8. What can we offer on vector database projects?

We are an Italian software engineering company, and we provide AI integrations, custom software and architecture services for organisations across EMEA and North America. Our engineering-first model means you work directly with the engineers who design and build your system, with no account-manager layer in between. That matters for vector projects, where decisions about embedding models, indexes and deployment are tightly coupled to business goals. We help teams implement embedding pipelines, RAG integrations and production deployments.

9. How does a vector database fit your existing data infrastructure?

Rarely does a vector database replace what you already run. It sits beside your system of record and is fed from it. A typical workflow starts when source data lands in your relational database, data lake or document store. A pipeline extracts and cleans it, passes chunks or records to an embedding model, writes the vectors and their metadata to the vector store, and lets the application query the vector store before fetching full records from the source by identifier.

Workflow from source data to vector retrieval

Several integration decisions deserve attention. First, decide where the truth lives. Keep canonical content in the system of record, and treat the vector index as a derived, rebuildable asset. Second, expose retrieval behind a narrow service interface so that application code does not depend on a specific engine, which makes a later migration far cheaper. Third, combine metadata filters with similarity ranking, for example restricting results to one language, product line or customer, because pure similarity ignores business rules.

In RAG systems, the retrieval service typically sits between the user interface and the language model, assembling context from the top matches and passing it into the prompt. For event-driven architectures, change events from the source database can trigger re-embedding automatically, so the index follows the data without manual jobs. Observability closes the loop: log query latency, recall proxies and empty-result rates, because relevance problems surface there before users report them.

10. How should you ingest and update vectors?

Ingestion begins with a decision on granularity. Documents are usually split into chunks, because one vector per long document blurs its meaning. Chunk size is a tuning parameter: small chunks give precise matches but lose context, large chunks keep context but dilute relevance. Overlap between chunks reduces the risk of cutting an idea in half.

Two ingestion modes cover most needs. Batch loading suits the initial population and periodic refreshes: it is simple, and many engines build better indexes when data arrives in bulk. Streaming or incremental updates suit data that changes continuously, such as support tickets or product catalogues, where you embed and upsert each new or modified item as it arrives.

Updates and deletions need explicit design. When a source document changes, its old vectors must be replaced, not merely supplemented, otherwise stale passages keep appearing in answers. Store the source identifier and a content hash with each vector, so you can detect changes cheaply and re-embed only what moved. Deletions matter for compliance as well as relevance: when a record is removed upstream, its vectors must disappear too. Note that some index types handle deletes by marking entries rather than removing them, so schedule periodic compaction or rebuilds.

Finally, plan for model changes. A new embedding model means a full re-embedding, so build the pipeline to run side by side with the old index and switch traffic only after you have compared quality on real queries.

11. What security and compliance issues are specific to vector databases?

Embeddings are not anonymous. A vector derived from personal or confidential text can leak information about it, and in some cases the original content can be partially reconstructed or inferred. Treat vectors as sensitive as the data they came from, and apply the same classification, retention and deletion rules.

Access control is the most common gap. Similarity search returns whatever is closest, regardless of who is asking, so a naive RAG system can surface a document the user should never see. Enforce permissions at retrieval time by storing access labels as metadata and filtering on them in every query, not by trusting the application layer to hide results afterwards. In multi-tenant systems, isolate tenants by collection or by mandatory filter.

Standard controls still apply: encryption in transit and at rest, authentication for the service interface, network segmentation, audit logging of queries, and tested backups. For European data subjects, GDPR obligations such as erasure and data minimisation reach the vector store as well, which links back to the deletion design described above. Residency also matters: embedding services that send text to an external API move that text outside your perimeter, so verify where the data is processed.

Security awareness around AI is also growing at enterprise level: Gartner reports that 34 percent of organisations are already using or implementing AI application security tools, a sign that protecting AI data paths is becoming a normal part of delivery.

11. What security and compliance issues are specific to vector databases? — overview diagram

12. Our take: start boring, measure early

The conventional advice is to pick the most scalable engine first. We think that is usually wrong. Teams can pay in operational complexity for capacity they will not need for a long time. A PostgreSQL extension, a clean schema and a disciplined ingestion pipeline carry a surprising number of products a long way.

What gets underestimated is everything around the index. Chunking strategy, metadata filters, permission checks and evaluation on real queries decide whether a RAG feature feels intelligent or unreliable. Teams spend weeks comparing ANN algorithms and an afternoon on how their documents are split, when the reverse allocation would serve them better.

So prioritise in this order: define a small set of real queries with known good answers, build the pipeline end to end on the simplest store you can run, measure recall and latency, and only then ask whether scale demands something heavier. Migration is easy if you kept identifiers and model versions clean. A rebuild forced by a hasty early choice is the expensive path.

— Pepe F.

13. Need an engineering partner for your vector database project?

If you would rather have experienced engineers carry a vector project into production, we can take it on directly:

  • AI and automation: embedding pipelines, RAG integrations and retrieval services.
  • Custom software development: the application layer around your search or recommendation features.
  • Architecture and technology stack: choosing between an extension and a dedicated engine for your scale.
  • CTO advisory: ongoing technical leadership, from CTO Advisory starting at €1,800 per month to fractional and partner arrangements.

Typical triggers are a production-grade deployment, a high-availability RAG pipeline, or the need for scale guidance. Read about our software development and architecture services and contact us to discuss your case.

Vicedomini Softworks

14. How do vector databases change search visibility?

Semantic retrieval is reshaping how content is found, not only inside applications but across the web. If you are curious about the discoverability side, this article on vector search and SEO looks at how rewriting pages for meaning-based retrieval can win citations in AI-driven search. The underlying idea is the same one this primer describes: systems that retrieve by meaning reward content that is clear, specific and well structured.

FAQ

What is a vector database used for?

A vector database is used to retrieve items by similarity of meaning. It powers semantic search, recommendations, anomaly detection and RAG, where a language model answers using passages retrieved from your own data.

What characterises a vector database?

A vector database is built to index and search high-dimensional embeddings. It typically relies on ANN algorithms for fast nearest-neighbour queries and stores metadata alongside each vector so results can be filtered.

Which are the main vector databases?

Options range from extensions to dedicated engines. PostgreSQL with pgvector suits teams already on PostgreSQL, while Milvus is a purpose-built system for larger or distributed workloads, as the Milvus and pgvector comparison describes.

What is a vector?

A vector is an ordered list of numbers that represents an item, such as a sentence or an image, in a high-dimensional space. Items with similar meaning or features get vectors that sit close together.

Sources

This article was produced with AI assistance and reviewed for accuracy. It is provided for general information only and is not professional advice.