Deploy PGvector & PGadmin on Docker and Ditch Pinecone

PGvector turns PostgreSQL into a self-hosted vector database. It lets you store, index, and query embeddings right inside Postgres instead of paying for a separate managed service. PGAdmin gives you a web UI to manage it. Together on Docker, you get a vector database stack running on a cheap VPS in under 10 minutes.

The original guide used the ankane/pgvector Docker image (abandoned since 2023) and an outdated Docker Compose format. This update fixes all of that: the official pgvector/pgvector:pg17 image, current Compose syntax, security improvements, and verification steps the original lacked.

If you’ve been paying for Pinecone or another managed vector database, this is the guide that lets you cancel that bill.

What is PGvector? PostgreSQL as a vector database

PGvector is a Postgres extension that adds vector similarity search to any PostgreSQL database. It supports exact and approximate nearest neighbor search with HNSW and IVFFlat indexing, distance operators for L2, cosine, and inner product, and up to 16,000 dimensions per vector (HNSW indexing supports up to 2,000 for full precision, 4,000 with halfvec, 64,000 with bit).

With 22,000+ GitHub stars, pgvector has become the default choice for teams that want vector search without running a separate service. The “one database for everything” argument is strong: your relational data and your embeddings live in the same Postgres instance. Same backup strategy, same access controls, same monitoring stack. No separate billing, no separate API keys.

Common use cases:

• RAG pipelines: store OpenAI or local LLM embeddings and retrieve relevant context for augmenting AI responses.
• Semantic search: find similar documents, products, or support tickets by vector distance instead of keyword matching.
• Recommendations: match users to items based on embedding similarity.
• Image/audio search: compare multimodal embeddings from CLIP or similar models.

For higher scale, TimescaleDB’s pgvectorscale extension adds StreamingDiskANN indexing on top of pgvector. Not needed for most setups, but it’s there when you outgrow basic HNSW.

Why ditch Pinecone? Updated pricing and cost comparison

The “ditch Pinecone” angle was relevant in 2024 when this article was first published. It’s gotten stronger since. In October 2025, Pinecone introduced a $50/month minimum on their Standard plan. That change effectively killed the hobby-tier use case and sent the vector database community looking for alternatives.

Pinecone’s $50/month minimum vs self-hosted pgvector

Here’s the cost math:

A Hetzner CX22 (2 vCPU, 4 GB RAM, 40 GB NVMe) at ~€5/month or a Hostinger VPS KVM plan handles pgvector for thousands of embeddings with no per-query charges. No usage caps. No surprise invoices. You can also check Vultr for global datacenter options.

The savings compound: Pinecone’s serverless pricing adds $0.33/GB/month for storage plus per-read/write units. At moderate traffic (10M reads/month), you’re looking at $82.50 in read charges alone on top of the base fee. pgvector on a VPS? Same flat €5–15/month regardless of query volume.

Vendor lock-in, latency, and other hidden costs

Beyond price, there’s the operational reality:

• Network latency: every vector query to Pinecone crosses the internet. A local Postgres query hits localhost. For RAG pipelines making dozens of lookups per request, that adds up fast.
• API key management: Pinecone requires API keys, rate limit awareness, and error handling for service outages. pgvector is just a Postgres connection.
• Data sovereignty: your embeddings (which often encode sensitive business knowledge) stay on your infrastructure. No third-party data processing agreements needed.
• Pricing risk: Pinecone already changed their pricing once. With self-hosted, your cost is whatever your VPS provider charges, and you can move providers anytime.

If you’re already running Docker for your app stack, you can also self-host your own infrastructure with Dokploy or use a self-hosted platform as a service like Coolify. The point is: you control the bill.

Prerequisites

Before you start, you need:

No Kubernetes, no external databases, no cloud accounts needed. Docker Compose handles everything.

If you’re looking for a good VPS deal, check Hetzner for cheap EU instances or Hostinger VPS for budget global options. For more container ideas, see our guide to self-hosted Docker containers for your home server.

Environment variables (.env file)

Create a .env file next to your compose file. These credentials configure both Postgres and PGAdmin:

POSTGRES_USER=pguser
POSTGRES_PASSWORD=change-me-use-a-strong-password
POSTGRES_DB=vectors
PGADMIN_DEFAULT_EMAIL=admin@example.com
PGADMIN_DEFAULT_PASSWORD=change-me-too

Replace the placeholder passwords with real ones. The POSTGRES_* variables configure the database; the PGADMIN_* variables set your PGAdmin login.

The compose file uses ${VAR:-default} syntax, so if you miss a variable it falls back to a default value. But don’t rely on defaults for credentials. Set them explicitly.

For more on how Docker handles environment variables, see environment variables in Docker Compose.

Docker Compose file for pgvector and PGAdmin

This is the core deliverable. Copy this into docker-compose.yml (or compose.yml, both work):

Complete docker-compose.yml

services:
  db:
    image: pgvector/pgvector:pg17
    container_name: pgvector_db
    restart: unless-stopped
    shm_size: '256mb'
    ports:
      - "127.0.0.1:5432:5432"
    environment:
      POSTGRES_DB: ${POSTGRES_DB:-vector}
      POSTGRES_USER: ${POSTGRES_USER:-user}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - ./local_pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-user} -d ${POSTGRES_DB:-vector}"]
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 10s

  pgadmin:
    image: dpage/pgadmin4:latest
    container_name: pgadmin4
    restart: unless-stopped
    ports:
      - "5016:80"
    environment:
      PGADMIN_DEFAULT_EMAIL: ${PGADMIN_DEFAULT_EMAIL}
      PGADMIN_DEFAULT_PASSWORD: ${PGADMIN_DEFAULT_PASSWORD}
    user: "${UID:-5050}:${GID:-5050}"
    volumes:
      - ./pgadmin-data:/var/lib/pgadmin
    depends_on:
      db:
        condition: service_healthy

What changed from the previous version

If you’re migrating from the old article’s compose file, here’s every change and why:

Deploy pgvector and PGAdmin with Docker Compose

With the compose file and .env in place, deploy:

# Pull the latest images
docker compose pull

# Start in detached mode
docker compose up -d

# Verify both containers are running
docker compose ps

# Check Postgres logs for errors
docker compose logs db

# Check PGAdmin logs
docker compose logs pgadmin

What success looks like: docker compose ps shows both pgvector_db and pgadmin4 as “Up”. The db service should show (healthy) in the status column after a few seconds.

What failure looks like: If db shows “unhealthy” or keeps restarting, check docker compose logs db. Common causes are port 5432 already in use on the host, or the data volume from a previous Postgres install with incompatible settings.

For more Docker commands and troubleshooting, see essential Docker commands.

If you are interested to monitor server resources like CPU, memory, disk space you can check: How To Monitor Server and Docker Resources

Accessing PGAdmin and connecting to pgvector

1. Open your browser to http://your-vps-ip:5016.
2. Log in with the PGADMIN_DEFAULT_EMAIL and PGADMIN_DEFAULT_PASSWORD from your .env file.
3. In PGAdmin, right-click Servers in the left panel → Register → Server.
4. In the General tab, give it a name (e.g., “pgvector”).
5. In the Connection tab, fill in:
   • Host name/address: pgvector_db (the container name, Docker resolves it via internal network)
   • Port: 5432
   • Username: the value of POSTGRES_USER from your .env
   • Password: the value of POSTGRES_PASSWORD from your .env
6. Click Save. The database should appear in PGAdmin’s browser panel.

Verify: Open a Query Tool (right-click the database → Query Tool) and run SELECT version(); to confirm the Postgres version.

After deployment: verify pgvector and create your first index

The original article stopped at “deploy.” That’s not enough. You need to confirm pgvector actually works, and understand how to index your data for real workloads.

Verify the pgvector extension is working

Open a Query Tool in PGAdmin (or run via docker compose exec db psql -U pguser -d vectors) and execute:

-- Enable the extension (first time per database)
CREATE EXTENSION IF NOT EXISTS vector;

-- Check the version
SELECT extversion FROM pg_extension WHERE extname = 'vector';
-- Should return '0.8.5' or similar

-- Test a simple vector operation
SELECT '[1,2,3]'::vector <-> '[4,5,6]'::vector AS distance;
-- Should return: 5.196152422706632

If the version query returns a value >= 0.8.2 and the distance query returns a number, pgvector is operational.

Create an HNSW index for fast similarity search

For any real use case, you need an index. Without one, pgvector does a sequential scan on every query. Fine for 100 rows, terrible for 100,000.

-- Create a table with a vector column
CREATE TABLE items (
    id bigserial PRIMARY KEY,
    content text,
    embedding vector(1536)  -- OpenAI ada-002 dimension
);

-- HNSW index (recommended for most use cases)
CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);

-- For production on large tables: create concurrently to avoid blocking writes
CREATE INDEX CONCURRENTLY ON items USING hnsw (embedding vector_cosine_ops);

-- Increase maintenance_work_mem for faster index builds
SET maintenance_work_mem = '2GB';

HNSW vs IVFFlat: which index should you use?

Default recommendation: Use HNSW. It’s the better choice for almost every workload. IVFFlat is only worth considering when you have a very large dataset where index build time is the bottleneck and you can tolerate slightly lower query accuracy.

CREATE EXTENSION IF NOT EXISTS vectorscale CASCADE;
CREATE INDEX ON items USING diskann (embedding vector_cosine_ops);

Configure Cloudflare Tunnel for secure remote access

Instead of opening PGAdmin’s port directly to the internet, you can expose it through a Cloudflare Tunnel. This gives you SSL, DDoS protection, and Cloudflare Access policies — without exposing your VPS IP address.

1. In the Cloudflare dashboard, go to Access → Tunnels.
2. Select your existing tunnel (or create a new one).
3. Add a hostname mapping your subdomain (e.g., pgadmin.yourdomain.com) to the service http://localhost:5016.
4. Save and wait for the tunnel to connect.

Once the tunnel is active, access PGAdmin at https://pgadmin.yourdomain.com with full Cloudflare protection.

Security best practices for your pgvector Docker setup

The updated compose file already addresses the biggest security issues from the original article. Here’s the full picture:

Remove POSTGRES_HOST_AUTH_METHOD=trust

Already done in the updated compose file. The old file included this setting, which disabled password authentication entirely. Anyone who could reach port 5432 could connect without credentials. If you’re migrating from the old setup, verify that POSTGRES_PASSWORD is set and update any connection strings.

Bind Postgres to localhost

The compose file binds 127.0.0.1:5432:5432 instead of 0.0.0.0:5432:5432. PGAdmin connects via Docker’s internal network (not the host port), so this only affects external access. If you need to reach Postgres from another server, use SSH tunnels or a VPN.

Use strong passwords and secure your .env

Don’t use pass or pgpass as your Postgres password. Generate random strings:

# Generate a random password
openssl rand -base64 32

Add .env to .gitignore. For production, consider securing your Docker Compose credentials with Docker secrets or a vault.

Keep pgvector updated

docker compose pull && docker compose up -d

Periodically check for updates. The pgvector/pgvector:pg17 tag follows the latest pgvector release for PostgreSQL 17. A docker compose pull && docker compose up -d gets you the latest patch.

Back up your vector database

The original article didn’t mention backups. For a self-hosted database, this is critical.

# Backup a single database
docker compose exec db pg_dump -U pguser vectors > backup_$(date +%F).sql

# Backup the entire cluster (all databases)
docker compose exec db pg_dumpall -U pguser > full_backup_$(date +%F).sql

# Restore from backup
docker compose exec -T db psql -U pguser vectors < backup_2026-07-21.sql

For automated backups, add pg_dump to a cron job and sync the output to S3-compatible storage. The ./local_pgdata volume directory can also be backed up directly — but stop the container first for a consistent snapshot, or use pg_dump for a live backup.

Scaling beyond the basics: halfvec, pgvectorscale and more

Once you have the basic setup running, pgvector has several levers for when your workload grows:

halfvec type (pgvector 0.7.0+) — stores vectors at half precision: 2 bytes per dimension instead of 4. OpenAI 1536-dim embeddings go from ~6 KB to ~3 KB each. Halves storage and memory costs.

sparsevec type (pgvector 0.7.0+) — sparse vectors for high-dimensional data where most values are zero. Useful for text search embeddings that use sparse representations.

Binary quantization via binary_quantize() — compress vectors to 1-bit per dimension. Massive storage savings at the cost of some recall accuracy. Good for initial filtering before a more precise reranking step.

ef_search tuning — HNSW parameter that trades query speed for recall accuracy. Higher values = better recall, slower queries. Default is 40; bump to 100+ for critical accuracy requirements.

CREATE EXTENSION IF NOT EXISTS vectorscale CASCADE;
CREATE INDEX ON items USING diskann (embedding vector_cosine_ops);

Conclusion

You now have a self-hosted vector database running PostgreSQL 17 with pgvector 0.8.5, managed through a PGAdmin web interface — all on Docker Compose. Total cost: whatever your VPS runs you (€5–15/month on Hetzner or Hostinger VPS). No per-query charges, no vendor lock-in, no pricing surprises.

Start with the basic setup. Verify the extension works, create an HNSW index, and run a few similarity queries. When you outgrow the basics, reach for halfvec or pgvectorscale.

If you’re building out your self-hosted stack, explore more self-hosted Docker containers for your home server or check out self-hosted server management panels for managing multiple services.