You do not always need a dedicated vector database. If you already run PostgreSQL, the pgvector extension turns it into a capable vector database, letting you store embeddings right next to your relational data and search them with plain SQL. For a lot of AI features, semantic search, recommendations, and small to mid-size RAG, that is the simplest and cheapest setup there is. This guide explains how Postgres as a vector database works with pgvector, how to set it up, when it is enough, and where to host it.
The short answer
pgvector is a PostgreSQL extension that adds a vector data type and similarity search, so you can store and query embeddings in the database you already use. It is ideal for small to mid-size workloads where keeping everything in Postgres beats running a second system. For very large scale, a dedicated database like Pinecone scales further.
What is pgvector?
pgvector is an open-source extension that gives PostgreSQL a native vector type and the operators to search it. Once it is installed, a table can have a column that holds an embedding, the array of numbers a model produces to represent text, an image, or other data. You can then find the rows whose vectors are closest to a query vector, which is the core operation behind semantic search and retrieval.
The appeal is that this happens inside Postgres. Your embeddings live alongside your normal columns, so you can filter, join, and order using the full power of SQL in the same query that does the vector search. There is no separate service to run, no data to keep in sync between two systems, and no new query language to learn. For teams already on Postgres, that simplicity is the whole point.
How to use Postgres as a vector database
Setting up pgvector is straightforward. The steps below are the shape of it, without getting lost in syntax.
1. Enable the extension. On a Postgres instance that has pgvector available, you enable it once with a single statement that creates the extension. Most managed Postgres providers either include it or let you turn it on.
2. Add a vector column. You create a table, or alter an existing one, to include a column of the vector type with the dimension your embedding model uses, for example 1,536 for many common models. Each row stores its embedding in that column next to whatever other data it has.
3. Insert your embeddings. You generate embeddings with your model of choice and insert them like any other value. Because it is just a column, you insert the vector alongside the text, the document ID, and any metadata in one row.
4. Search by similarity. To retrieve, you embed the query and run a SELECT that orders rows by distance to that query vector, returning the closest matches. The powerful part is that you can add normal WHERE clauses in the same query, so filtering by user, date, or category happens together with the vector search.
5. Add an index. For anything beyond a small table, you add an approximate index so searches stay fast as the data grows. pgvector supports index types that trade a little recall for a lot of speed, which is what makes it practical at scale.
Indexing: keeping searches fast
Without an index, Postgres compares your query vector to every row, which is fine for a few thousand rows and slow for millions. pgvector offers approximate nearest neighbor indexes that group similar vectors so a search only checks a fraction of the data. The two main choices trade off differently: one builds faster and updates more easily, the other can give higher recall for a given speed once tuned. The practical advice is to add an index as soon as your table grows, pick sensible defaults to start, and tune the parameters if you need to push recall or latency. Getting indexing right is the difference between pgvector feeling instant and feeling sluggish.
When Postgres with pgvector is the right choice
pgvector is not a compromise for many use cases. It is genuinely the best fit when the following are true.
You already run Postgres. If your app’s data is already in Postgres, adding vectors there avoids standing up and syncing a second database, which is a real and ongoing cost.
Your corpus is small to mid-size. For thousands to low millions of vectors, pgvector with a good index is fast and more than capable for semantic search and RAG.
You need to filter and join. When retrieval has to combine vector similarity with relational conditions, doing it in one SQL query is cleaner and often faster than coordinating two systems.
You want to keep costs and complexity low. One database to run, back up, and reason about is simpler and cheaper than two.
For a broader look at the options, see our guide to the best vector database for RAG and the best vector databases overall.
When to use a dedicated vector database instead
pgvector has limits, and it is worth knowing where they are. At very large scale, hundreds of millions of vectors or very high query throughput, a purpose-built vector database will outperform it and scale more smoothly, since that is all it is designed to do. Dedicated databases also offer features pgvector handles less natively, like first-class hybrid search combining keywords and vectors, advanced filtering at scale, and managed serverless scaling with no tuning.
The pragmatic path many teams take is to start on pgvector and graduate later if they outgrow it. If you reach that point, a managed option like Pinecone takes the operational burden off your hands, scaling to billions of vectors with strong filtering and hybrid search and nothing to tune. There is no shame in either choice: pgvector for simplicity now, a dedicated database when scale demands it.
Outgrowing pgvector? Try Pinecone
When your corpus or query volume gets too big for Postgres, Pinecone scales to billions of vectors with managed serverless infrastructure, hybrid search, and no tuning. The natural next step.
Where to host Postgres with pgvector
To use pgvector you need a Postgres instance that supports it, and you have a few good options depending on how much you want to manage.
Managed Postgres on a platform like Railway. The simplest route is to add a managed Postgres database on Railway in one click, enable pgvector, and connect it to your app, which you can deploy on the same platform with private networking between them. There is no server to manage, and your app and database live together.
A VPS you control. If you want full control or a fixed cost, run Postgres yourself on a VPS like Cloudways or Hostinger, install pgvector, and manage backups and updates yourself.
A managed database service. Many managed Postgres providers now include pgvector, so you can enable it without any server administration at all.
Whichever you pick, the database is the part that matters: keep it backed up, size it for your workload, and enable pgvector before you start inserting vectors.
Run Postgres and your app on Railway
Add managed Postgres in one click, enable pgvector, and deploy your app next to it with private networking. The simplest way to host a Postgres vector database.
Frequently asked questions
Can PostgreSQL be used as a vector database? Yes. With the pgvector extension, Postgres gains a vector data type and similarity search, so you can store and query embeddings directly. For small to mid-size workloads it is a capable vector database without running a separate system.
Is pgvector good enough for production? For many production apps, yes, particularly semantic search, recommendations, and small to mid-size RAG. At very large scale or very high query volume, a dedicated vector database like Pinecone scales further and offers more advanced features.
Do I need a separate vector database if I use pgvector? Not while you are within pgvector’s comfort zone, which covers a lot of real apps. Keeping vectors in Postgres avoids syncing two systems. You move to a dedicated database only when scale or features demand it.
How do I make pgvector searches fast? Add an approximate nearest neighbor index once your table grows beyond a few thousand rows. Without one, Postgres scans every row. With a well-tuned index, searches stay fast into the millions of vectors.
Where can I host pgvector? Anywhere you can run Postgres with the extension enabled: managed Postgres on a platform like Railway, a VPS you control, or a managed database service that includes pgvector. Railway is the simplest if you want your app and database together.
The bottom line
For a great many AI features, you do not need a separate vector database at all. With pgvector, PostgreSQL stores your embeddings next to your relational data and searches them with plain SQL, which keeps your stack simple, cheap, and easy to reason about. Use it whenever you already run Postgres and your corpus is small to mid-size, add an index as you grow, and host it on managed Postgres like Railway for the least fuss. If you eventually outgrow it, a managed database like Pinecone is the natural next step. Start simple in Postgres, and scale up only when you genuinely need to.
