A Short History of Vector Search Inside the Database

Hello,

In short: For years the "meaning" search of artificial intelligence (vector search) lived outside the database, in a separate system. In 2024 and 2025 both SQL Server 2025 and PostgreSQL brought it inside the engine, right next to the data. In this post I tell that journey as a dated chronology and give a practical example from each side.

I want to do something slightly different in this post: rather than a feature, I will describe a direction of travel. Because something quiet but very large happened in the database world in recent years. The "meaning search" at the heart of AI lived for a long time outside the database in a separately installed box, then came back and settled right inside the database.

What is interesting is that both the SQL Server side and the PostgreSQL side did this in almost the same period, independently of each other. Because I have worked in both worlds for years I watched this convergence closely. Let us build it from the start: what we used to do and how, what changed when, and how we do it today. I verified every date against its source one by one.

A short glossary first: what are embeddings and vector search?

Let me settle it quickly, because the whole story turns on this concept.

An embedding is turning a piece of text (or an image) into a series of numbers, that is into a vector. That series of numbers represents the "meaning" of the text. Two texts close in meaning end up with vectors close to each other. "Dog" and "cat" are close, "dog" and "invoice" are far apart.

Vector search does exactly that: it says "bring me the records closest in meaning to this". In classic search, typing "dog" gets you only the rows containing "dog". In vector search, typing "pet" brings back records about dogs and cats even though that word never appears. That is what lies beneath the part of AI that feels like it "understands". And RAG (AI fed with your own data), today's most popular pattern, is built on top of this search.

The timeline: from 2008 to 2026

Let me put the whole picture down first, then open it period by period. Every date in the table is verified against its source.

Date	Event	What changed
2008	PostgreSQL 8.3: tsvector entered the core	Search = word matching (full-text). No meaning. SQL Server had this since 1998 (7.0).
2017	Facebook open sourced FAISS	The technical foundation of vector similarity search was laid.
2019	Milvus, Weaviate and Pinecone appeared	A separate "vector database" category was born.
2020	The term RAG appeared (Lewis and colleagues)	The idea of feeding AI with external knowledge entered the literature.
Apr 2021	pgvector 0.1.0 (Andrew Kane)	Vectors entered a relational database (PostgreSQL) for the first time.
Dec 2022	OpenAI text-embedding-ada-002	Embeddings became cheap and standardised; RAG exploded with the ChatGPT wave.
Aug 2023	pgvector 0.5.0: the HNSW index	Vector search in PostgreSQL got seriously faster.
Nov 2024	Azure SQL: native vector support (public preview)	The Microsoft side formally entered the game.
Nov 2024	Anthropic open sourced MCP (with a Postgres server in the box)	The standard for connecting AI to live data was born. The same month!
Jun 2025	Azure SQL: the native VECTOR type went GA	It became production ready in the cloud.
Nov 2025	SQL Server 2025: the VECTOR type GA; the DiskANN index in public preview	Vector search is now inside the on-premises SQL engine.
2025	OpenAI, Google and Microsoft adopted MCP; in December it was handed to the Linux Foundation	MCP became the industry's shared standard.
2026	Vectors + MCP: the database becomes a full AI platform	The convergence completed: it both carries meaning and is reachable live.

Yesterday: search was words, not meaning

At the start everything was "words". If we searched text in a table we would either write a simple LIKE '%dog%' or use full-text search for more serious work. PostgreSQL brought that into the core in 2008 with tsvector in version 8.3 (source). On the SQL Server side full-text search goes much further back, to version 7.0 in 1998.

These methods are still valuable but they have a boundary: they find the word, not the meaning. They cannot bring "car" to someone searching for "automobile", because to them those are two different words. Where a human says "the same thing", the machine says "different". In the AI age what we actually needed was the opposite: catching meaning rather than words.

The interim period: we moved AI outside the database

The technical foundation of meaning search was actually laid much earlier, in 2017, when Facebook open sourced the FAISS library (source). Then in 2019 tools such as Milvus, Weaviate and Pinecone appeared, and a new category was born: the vector database.

At the end of 2022 two things happened at once: ChatGPT entered our lives, and OpenAI made generating embeddings both cheap and standardised with the text-embedding-ada-002 model (source). Suddenly everyone wanted to build RAG. And the standard architecture of that period was this: your actual data sat in SQL Server or PostgreSQL, but you took the embeddings and wrote them to a separate vector database.

That method worked but it came at a price. You were now operating two separate systems. There were two copies of the data and you had to keep them in sync. When a record was updated you had to update its embedding, when it was deleted you had to delete it there too. And then security, backups, permissions, you had to solve all of it twice. In short a whole extra piece had been added to the architecture.

Honestly I built that architecture a lot in that period, and every time I had the same small discomfort: "I already keep this data in the database; could I not keep the embedding there too?" It turned out thousands of people were asking that question alongside me. And the answer was not long in coming.

The turning point: pgvector and "why should it live somewhere else?"

The PostgreSQL side was the first to take that question seriously. In April 2021 Andrew Kane published the first release of the pgvector extension and brought vectors directly into PostgreSQL as a data type. Which meant you could keep the embedding right next to the row it belonged to, in the same table.

It was slow at first but matured quickly. Version 0.5.0, arriving in August 2023, added the HNSW index and sped search up considerably (source). Later versions brought parallel index building and new vector types. Today pgvector is a mature and fast solution used in production at places such as OpenAI and Supabase. Extensions alongside it such as pgvectorscale strengthened the scale side too.

The idea here was revolutionary: if my data is already in the database, why would I move the embedding somewhere else? I can keep it here too and look at both meaning and relational filters in a single query.

The Microsoft side: SQL Server 2025 and the native VECTOR type

Microsoft walked the same way, only a little later and step by step. First, in November 2024, it announced native vector support in Azure SQL Database as a public preview (source). Then in June 2025 the native VECTOR type and its functions became generally available in Azure SQL (source).

The really big step came in November 2025: with SQL Server 2025 the native VECTOR data type went GA inside the on-premises engine too. So you can now store embeddings in SQL Server next to the rows they belong to and run meaning search (source).

The GA / preview distinction (be careful): The native VECTOR type is GA (June 2025 in Azure SQL, November 2025 in SQL Server 2025). But the DiskANN based vector index that speeds up high scale search is still public preview in SQL Server 2025 and private preview in Azure SQL. Do not miss that distinction when making a production decision: the type is ready, the index is not GA yet.

Today: the same job on both sides, next to the data

Now we come to my favourite part. As someone who writes on both sides, I enjoy putting the same idea side by side in two worlds. Both are really saying the same thing: "bring me the 5 records closest to this vector." Only the words differ, the logic is identical.

The SQL Server 2025 side. You create a column with the VECTOR type and measure distance with VECTOR_DISTANCE:

 -- embedding kolonu, urun satirinin tam yaninda durur CREATE TABLE urunler ( id INT PRIMARY KEY, ad NVARCHAR(200), aciklama NVARCHAR(MAX), embedding VECTOR(1536) -- yerel VECTOR tipi (GA) ); -- "Su vektore anlamca en yakin 5 urun" (kosinus mesafesi) SELECT TOP (5) id, ad, VECTOR_DISTANCE('cosine', embedding, @sorgu_vektoru) AS mesafe FROM urunler ORDER BY mesafe; 

The PostgreSQL (pgvector) side. The same logic, this time with the vector type and the <=> (cosine distance) operator:

 CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE urunler ( id INT PRIMARY KEY, ad TEXT, aciklama TEXT, embedding vector(1536) -- pgvector tipi ); -- Aramayi hizlandiran HNSW indeksi CREATE INDEX ON urunler USING hnsw (embedding vector_cosine_ops); -- "Su vektore anlamca en yakin 5 urun" SELECT id, ad FROM urunler ORDER BY embedding <=> :sorgu_vektoru LIMIT 5; 

Notice in both examples: the vector is not in a separate system, it sits inside the urunler table right next to the product. And that is where the real door opens.

The real win: meaning and filtering in a single query

The biggest benefit of bringing the vector next to the data is this: you can now combine meaning search with a classic filter in a single query. While saying "the products closest in meaning to this description" you can at the same time say "but only the ones in stock and under 500 lira".

 SELECT TOP (5) id, ad, fiyat, VECTOR_DISTANCE('cosine', embedding, @sorgu_vektoru) AS mesafe FROM urunler WHERE stok > 0 AND fiyat < 500 -- klasik filtre ORDER BY mesafe; -- anlamsal siralama 

Doing that with a separate vector database would mean making two systems talk and merging the results in the application. Here it is one query, one engine, one consistent result. Because the embeddings sit next to the data, joins, transactions and row-level security come free (source). That is exactly what lies at the heart of RAG architecture: finding the records closest in meaning to the user's question and compliant with the rules, and giving them to the AI as context.

So is the separate vector database finished?

No, and to be honest the answer is "it depends". You can tell them apart like this:

• If your data is already in SQL Server or PostgreSQL and your vector count is at a reasonable scale (the threshold quoted in practice is between a few million and ten million vectors on standard hardware; source), the embedded solution is usually the right one. One system, one backup, one security model, less complexity.
• If you have hundreds of millions of vectors, very high query volume or a very specific performance need, a purpose built vector database (Milvus, Qdrant, Pinecone and so on) can still make sense.

The general trend of 2026 is clear: vectors are no longer seen as a separate product category but as a data type that relational databases support too. So much so that Snowflake and Databricks spent roughly $1.25 billion on PostgreSQL focused companies in 2025 (source). The idea that "the database is an AI platform" is no longer a prediction but a reality the industry is investing in.

And what about MCP? Bringing the knowledge is not enough, access is needed too

So far we have talked about how to bring the data and its meaning to the AI. Vector search and RAG do exactly that: they find the knowledge closest to the user's question and give it to the model as context. But there is another side to the coin. Bringing knowledge is one thing; the AI being able to connect live to that database, ask for its current state and even do work within safe boundaries is something else entirely.

The thing that filled that gap became the fastest spreading standard of the last year: MCP (Model Context Protocol). In brief MCP is an open protocol letting AI applications connect to external systems such as databases, files and APIs in a standard, two way manner. Think of it like this: RAG brings the meaning of the data as a "photograph"; MCP gives the AI a live "door" into your database.

The timing is striking too. Anthropic published MCP as open source in November 2024, almost the same month Azure SQL announced native vector support. And a Postgres server was among the ready servers in the box from day one (source). So the idea of "connecting AI to the database" was on the agenda the day MCP was born.

What followed came fast: through 2025 OpenAI (March), Google (April) and Microsoft (May) adopted MCP in turn; and in December Anthropic handed the protocol to an independent foundation under the Linux Foundation (source). So MCP is no longer one company's but the industry's shared standard. That degree of consensus is rare in technology.

Why does it matter? Because AI's next step is moving from "summarising text" to "doing work". Vector search enriches what the model knows; MCP widens what the model can do. Put the two together and your database genuinely turns into an AI platform: it carries meaning (vectors) and becomes reachable live within safe boundaries (MCP).

The progression runs along this line:

• Yesterday: AI knew only the general knowledge it was trained on; it had no idea about your data.
• With RAG: you could add your own static data as context (vector search comes in right here).
• With MCP: AI can connect to the live, current state of your database; designed correctly it can run queries and take actions within safe boundaries.
• Tomorrow: when those two combine, AI agents that talk to your data, see its state instantly and act safely will become standard.

Let us not keep it abstract; here is what MCP looks like in practice. Below is a simple MCP tool an AI client could call. Something familiar is hiding inside it: the pgvector search we just saw. So when the AI says "search products", a vector search is really running behind the scenes.

 from mcp.server.fastmcp import FastMCP import psycopg mcp = FastMCP("urun-arama") @mcp.tool() def urun_ara(sorgu_metni: str, adet: int = 5) -> list[dict]: """Verilen metne anlamca en yakin urunleri getirir.""" vektor = embed(sorgu_metni) # metni embedding'e cevir with psycopg.connect(DSN) as conn: rows = conn.execute( "SELECT id, ad FROM urunler " "ORDER BY embedding <=> %s LIMIT %s", # iste pgvector aramasi (vektor, adet), ).fetchall() return [{"id": r[0], "ad": r[1]} for r in rows] if __name__ == "__main__": mcp.run() 

Notice: this tool only reads, it writes nothing. The way to make MCP safe hides in that very sentence: do not give a tool one bit more permission than the job requires. The AI can say "search products" but cannot say "delete product", because no such tool is defined.

I work closely on this side too. Have a look at my post on an MCP server for SQL diagnostics, where I go step by step through connecting SQL Server to an AI client with MCP, using a safe read only approach. There is a working example there rather than theory.

MCP is powerful, but a door opens both ways

Now to the shadow side of the coin, because we should not let excitement blind us. If MCP gives AI a live door into your database, remember this: a door opens both ways. The same channel, designed wrongly, can turn into a serious security surface.

A few concrete examples, without exaggeration:

• Prompt injection. An attacker hides commands in content the AI processes; the model cannot tell the legitimate instruction from the malicious one and runs both. This is the number one vulnerability on OWASP's 2025 LLM security list (source).
• Tool poisoning. The command is hidden not in user input but in the tool's own definition. In 2025 Invariant Labs showed that a malicious MCP server could silently exfiltrate a user's entire message history (source).
• Excessive permission. In the Supabase/Cursor incident of June 2025, a privileged agent was tricked into leaking secret access keys by a command hidden in a user support request. A critical vulnerability with a CVSS of 9.4, where an unauthenticated MCP tool was open to remote command execution, was also reported (CVE-2025-49596).

That is why I put security at the centre when designing my own MCP server: it runs read only, no write tool is defined, and it connects with a least privileged account. Because the rule is simple: every permission you give the AI can also be a permission you give an attacker. The right question is not "what should the AI be able to do?" but "what must it be unable to do in the worst case?".

And the bigger picture: data sovereignty

There is a topic as important as security, perhaps even more strategic: data sovereignty. That is, where your data sits, which law it is subject to and who can reach it.

At the start of the story we talked about why we sent embeddings to a separate vector database or an external service. Now see the hidden cost: taking data out along with its meaning usually means taking it outside your own border and your own control. Whereas keeping the vector in your own PostgreSQL or SQL Server means keeping the data on its own soil, under your own rules.

This is no longer an academic debate. In 2026 the trend has shifted from "where the data sits" (data residency) to "who controls the stack" (technical sovereignty) (source). The EU AI Act comes fully into force for high risk systems on 2 August 2026; the era of "accidental compliance" is over. On our side KVKK asks the same questions: where is this data, who reaches it, why?

This is where the real beauty of keeping the vector next to the data appears: it is not only more practical (one system), it is also a more sovereign decision. Your data, its meaning and the AI reaching it all stay under your control. I described how I frame this approach as "observe, govern, act" in more depth in the 2026 Data Platform Manifesto: Data Sovereignty (in Turkish).

What does this journey tell you?

To my mind the real lesson here is not technical but strategic. For years we thought "we must build separate, special systems for AI". The direction of travel showed the opposite: the soundest route usually runs through managing the database you already have well, and bringing the AI to it, next to the data.

Because a vector type does not save you from one big truth: adding vectors on top of a badly managed, messy, weakly secured database does not make it AI ready. On the contrary, it carries the problems over to the AI as well. A solid, well managed database becomes the shared and trustworthy ground for both your classic work and the AI side.

So what is next? A small prediction

Everything I have described so far was proven, dated and already done. Now, with your permission, let me put on my fortune teller's hat for a few minutes. What follows is not certain knowledge but my predictions based on the direction I read. If I am wrong this post stays here and you can come back and laugh.

1. The real issue will shift from "access" to "governance". Vectors brought the meaning of the data and MCP solved live access. So the question "how does AI reach the data" has largely been answered. The question that will occupy everyone from now on is: since every AI can reach every piece of data, who should reach what, when and within which boundary? Value will shift from opening access to monitoring, governing and auditing it. "Observe first, govern next, permit last" will stop being a preference and become a necessity.

2. You will not even generate the embeddings yourself. Today we still mostly take the text and turn it into an embedding by hand, sending it to an external model. In the next step the database itself will do that work: the moment you insert the row, the engine will produce the embedding and place it alongside. Once the vector is a "data type", generating an embedding will start to look like an ordinary column computation.

3. AI will move from "answering" to "doing". MCP's real promise is not conversation but action. In the coming period, data agents that run queries on their own within safe boundaries, see the state and take steps, will become normal. That is both the exciting and the alarming part; and precisely for that reason the governance in item one will be the precondition for everything else.

In short, my bet is this: the next big story will not be "how does AI reach the data" but "how do we govern that access safely". And that puts the people who manage databases right in the middle of the stage. For those who take this work seriously, things are only just beginning.

If you want to keep this ground solid

Whether you are on the SQL Server or the PostgreSQL side, the precondition for genuinely benefiting from vector and AI features is a solid, well managed database underneath. If performance, backups, security and currency are not in place, even the brightest AI feature will not give you what you expect.

DMC Bilgi Teknolojileri builds and maintains exactly that ground with its Managed Database Service: the health, performance and security of your SQL Server and PostgreSQL environments are monitored regularly, and while you focus on the business and the AI side the foundation of the data stays solid. If you want to talk about your needs you can get in touch with the DMC team.

You might also look at the database's new test in the age of AI agents, where I cover the new responsibilities AI expects from the database more broadly, and Data Quality = AI Quality, where I describe how data quality determines the AI.

Frequently asked questions

What is vector search?

Vector search is turning text or images into series of numbers (vectors or embeddings) representing their meaning, then answering the question "which records are closest in meaning to this". The difference from classic search is that it looks at closeness in meaning rather than word matching.

Does SQL Server support vector search?

Yes. With SQL Server 2025 the native VECTOR data type became generally available (November 2025); the same type went GA in Azure SQL in June 2025. But the DiskANN based index that speeds up high scale search was still in public preview at the time of writing.

How do you do vector search in PostgreSQL?

With the pgvector extension. You create a column of type vector, build an index such as HNSW, and query the closest records with operators such as <=> (cosine). pgvector is open source and widely used in production.

Do I still need a separate vector database?

In most cases no. If your data is already in SQL Server or PostgreSQL and your vector scale is reasonable, the embedded vector support is usually enough and simpler. For hundreds of millions of vectors or very specific performance needs, purpose built vector databases can still make sense.

Does adding a vector type make my database AI ready?

On its own, no. Vector search is a powerful capability but it does not fix messy, badly managed data. The precondition for being AI ready is a solid, current and well managed database underneath.

What is MCP, and how does it differ from vector search?

MCP (Model Context Protocol) is an open protocol letting AI applications connect to external systems such as databases in a standard, two way manner; Anthropic published it in November 2024 and it became the industry's shared standard in 2025. Vector search brings the meaning of the data as context; MCP gives the AI access to the live database. The two complement each other: one provides the knowledge, the other the live connection.

Is MCP safe for my database?

MCP itself is a door; its safety depends on how you design it. There are real risks such as prompt injection and tool poisoning (prompt injection is number one on OWASP's 2025 list). The right approach: read only and least privileged access, only trusted MCP servers, strict auditing and logging. Assume every permission you give the AI could also be used by an attacker.

Why does keeping the vector in my own database matter for data sovereignty?

Sending an embedding to an external vector database or service usually means taking the data, along with its meaning, outside your own border and control. Keeping the vector in your own SQL Server or PostgreSQL keeps the data on its own soil, under your own rules (KVKK, the EU AI Act). In 2026 that is not a compliance detail but a strategic control decision.

Summary

The story of vector search is really a story of return. We first tried to solve the need to capture meaning outside the database, in separate systems. Then both PostgreSQL (with pgvector since 2021) and SQL Server (with the native VECTOR type in 2025) brought it inside the engine, right next to the data.

Add MCP on top and the picture is complete: vector search brings the meaning of the data to the AI, and MCP provides live access. One grows what it knows, the other what it can do. Together they turn your database into a genuine AI platform.

Where we stand today is this: AI's meaning search is now a natural part of your database. But remember, that capability only works on the ground of a solid, secure database under your own control. Foundation first, then intelligence; and all of it on your own soil.

Which side are you trying vector search on, SQL Server or PostgreSQL, or are you still on a separate vector database?