Deploy and Host VectorChord on Railway

Built for an LLM agent to deploy and use. There is no setup step and nothing to fill in: a 32-character password is generated at deploy time, a database named railway is created, and the vchord and vector extensions are already enabled in it. The contract below lists every URL, variable name and the one script that proves it works.

VectorChord is a PostgreSQL extension for vector similarity search from TensorChord, the successor to pgvecto.rs. It adds the vchordrq index, an IVF index with RaBitQ quantization, on top of pgvector's vector type, so embeddings from an LLM or an embedding model are searched with plain SQL. It is used for RAG, semantic search, recommendations and agent memory on a database you already know how to run.

About Hosting VectorChord

This template runs one service, vectorchord, built from the official tensorchord/vchord-postgres image (VectorChord 1.1.1 with pgvector 0.8.2 on PostgreSQL 18, pinned by digest). The start command preloads vchord and vector, creates both extensions in the railway database on first boot, and then hands over to the stock Postgres entrypoint. The data volume is mounted at /var/lib/postgresql and PGDATA stays at its default subdirectory, so the lost+found folder Railway puts at the volume root never lands inside the data directory. The start command runs as root so the root-owned volume is writable, and prints the user id and mount owner in the deploy log. shared_buffers, effective_cache_size, work_mem and the worker counts are computed from the container limits, not from the host's RAM. The database port is exposed on a Railway TCP proxy; services in the same project use the private address.

VectorChord is dual licensed under AGPLv3 and Elastic License v2. This template deploys the unmodified upstream image for the deployer's own use.

Agent contract

Public URL: none over HTTP. The database is reached on the TCP proxy as DATABASE_URL (host RAILWAY_TCP_PROXY_DOMAIN, port RAILWAY_TCP_PROXY_PORT).
Private URL: postgresql://postgres:POSTGRES_PASSWORD@vectorchord.railway.internal:5432/railway, exposed as DATABASE_PRIVATE_URL.
Credentials: user postgres, password in POSTGRES_PASSWORD, database railway.
Auth: PostgreSQL password authentication (SCRAM-SHA-256) in the connection string. A wrong password is refused. The server does not offer TLS, so use the private URL for anything sensitive.
Health: no HTTP health path (a TCP proxy and an HTTP healthcheck cannot share a service). Readiness is pg_isready -d "$DATABASE_URL" returning accepting connections, or a successful psql "$DATABASE_URL" -c 'select 1'.

# run with DATABASE_URL set; needs psql
until pg_isready -q -d "$DATABASE_URL"; do sleep 2; done
psql "$DATABASE_URL" -q -v ON_ERROR_STOP=1 -At \
  -c "select 'vchord ' || extversion from pg_extension where extname = 'vchord'" \
  -c "select 'vector ' || extversion from pg_extension where extname = 'vector'" \
  -c "drop table if exists agent_docs" \
  -c "create table agent_docs (id bigint primary key, body text, embedding vector(3))" \
  -c "insert into agent_docs select g, 'doc ' || g, array[g % 7, g % 11, g % 13]::real[]::vector(3) from generate_series(1, 1000) g" \
  -c "create index on agent_docs using vchordrq (embedding vector_l2_ops) with (options = E'residual_quantization = true\n[build.internal]\nlists = []')" \
  -c "select 'rows ' || count(*) from agent_docs" \
  -c "select 'nearest ' || id from agent_docs order by l2_distance(embedding, '[3,4,5]') limit 1"

A fresh deploy prints vchord 1.1.1, vector 0.8.2, rows 1000 and nearest 213. Run it again and it prints the same, because the table is dropped first. Postgres INFO lines about clustering go to stderr.

Why Deploy VectorChord 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 VectorChord 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.

Agent-ready - generated password, contract block and one working script; no setup step.
Extensions on from the first boot - vchordrq indexes and pgvector's vector type work immediately, with no CREATE EXTENSION and no preload settings to edit.
Official image, pinned - the TensorChord image is pinned by digest, so a redeploy never changes the server underneath you.
State survives redeploys - the volume is mounted one level above PGDATA, so the data directory is never polluted by lost+found.
Right-sized - Postgres memory and worker settings come from the container limits.

Common Use Cases

RAG and semantic search - store document embeddings next to the rows they describe and query them with SQL.
Agent memory - give an agent a durable vector store that survives restarts and redeploys.
Recommendations - nearest-neighbour lookups over item or user embeddings.

Dependencies for VectorChord Hosting

One Railway volume for the data directory (created by the template).

Deployment Dependencies

VectorChord documentation
Official image
tensorchord/VectorChord - upstream project

Implementation Details

Variable	Purpose
`POSTGRES_PASSWORD`	Password of the `postgres` user, generated per deploy.
`DATABASE_PRIVATE_URL`	Connection string on the private network, for services in the same project.
`DATABASE_URL`	Connection string on the TCP proxy, for clients outside Railway.