Deploy pgvector

Deploy and Host pgvector on Railway

pgvector is an open-source PostgreSQL extension that adds vector similarity search directly to PostgreSQL. It allows you to store embeddings alongside relational data and query them using exact or approximate nearest-neighbor search, making it useful for RAG, semantic search, recommendation systems, and AI applications.

About Hosting pgvector

Hosting pgvector on Railway gives you a persistent PostgreSQL database with vector search capabilities without introducing a separate vector database into your stack.

This template uses the official pgvector PostgreSQL image and stores database data in a persistent Railway volume. Applications can connect using the PostgreSQL wire protocol on port 5432.

pgvector is installed in the image, but the extension must be enabled once inside the database before vector columns and operators can be used.

Common Use Cases

• Retrieval-Augmented Generation (RAG)
• Semantic and similarity search
• Embedding storage inside PostgreSQL
• Recommendation systems
• AI application memory
• Hybrid relational and vector workloads
• Applications that already use PostgreSQL and need vector search

Dependencies for pgvector Hosting

• Official pgvector/pgvector Docker image
• Persistent Railway volume mounted at /var/lib/postgresql/data

Implementation Details

This template runs PostgreSQL with pgvector pre-installed.

The database uses:

TCP / PostgreSQL Protocol
Port 5432

Persistent database files are stored in:

/var/lib/postgresql/data

No Redis, object storage, external metadata service, or additional database is required.

Database Connection

Applications running inside the same Railway project should preferably use the private connection URL:

${{pgvector.DATABASE_URL_PRIVATE}}

External tools and applications can connect through Railway's TCP Proxy using:

${{pgvector.DATABASE_URL}}

You can also use the individual PostgreSQL connection variables exposed by the service, including host, port, database name, username, and password.

Because PostgreSQL uses the PostgreSQL wire protocol rather than HTTP, external connections use a TCP Proxy, not a Railway HTTP public domain.

Enable pgvector

After connecting to the database, enable pgvector in the database where you want to use vector functionality:

CREATE EXTENSION IF NOT EXISTS vector;

This only needs to be done once per database.

You can verify the installation with:

SELECT extname, extversion
FROM pg_extension
WHERE extname = 'vector';

Quick Vector Search Test

Create a simple vector table:

CREATE TABLE items (
    id BIGSERIAL PRIMARY KEY,
    embedding VECTOR(3)
);

Insert sample vectors:

INSERT INTO items (embedding)
VALUES
    ('[1,2,3]'),
    ('[4,5,6]');

Run a nearest-neighbor query:

SELECT *
FROM items
ORDER BY embedding <-> '[3,1,2]'
LIMIT 5;

Using pgvector for Embeddings

A typical AI application may store text and embeddings together:

CREATE TABLE documents (
    id BIGSERIAL PRIMARY KEY,
    content TEXT,
    embedding VECTOR(1536)
);

The vector dimension must match the embedding model used by your application.

For example:

INSERT INTO documents (content, embedding)
VALUES (
    'Sample document',
    '[0.1, 0.2, 0.3, ...]'
);

Distance Operators

pgvector provides multiple operators for different similarity calculations:

Example cosine similarity search:

SELECT content
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, 0.3, ...]'
LIMIT 10;

Vector Indexes

pgvector supports exact search by default and approximate nearest-neighbor indexes when faster search is required on larger datasets.

HNSW

CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops);

HNSW generally provides a strong speed and recall tradeoff, but requires more memory and can take longer to build.

IVFFlat

CREATE INDEX ON documents
USING ivfflat (embedding vector_l2_ops)
WITH (lists = 100);

IVFFlat generally builds faster and uses less memory than HNSW, but requires tuning to balance query speed and recall.

Both HNSW and IVFFlat are approximate nearest-neighbor indexes.

Without either index, pgvector performs exact nearest-neighbor search.

pgvector vs Dedicated Vector Databases

pgvector is particularly useful when your application already relies on PostgreSQL and you want vector search without operating a separate vector database.

It allows traditional relational data, JSON, transactions, SQL queries, and embeddings to remain in the same database.

Dedicated vector databases such as Qdrant, Weaviate, and Milvus may be more appropriate when vector search is the primary workload or when a specialized distributed vector architecture is required.

Getting Started After Deployment

1. Deploy the pgvector template.
2. Wait for PostgreSQL to become available.
3. Retrieve the connection URL from the Railway service variables.
4. Connect using psql, DBeaver, DataGrip, pgAdmin, or your application.
5. Run:

CREATE EXTENSION IF NOT EXISTS vector;

6. Create your first table with a VECTOR(n) column.
7. Insert embeddings.
8. Run similarity queries using <->, <=>, or <#>.
9. Add HNSW or IVFFlat indexes when your dataset requires faster approximate search.

Why Deploy pgvector on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying pgvector on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.