VPS para una base de datos PostgreSQL (autoalojada, control total)

Hay un momento en que PostgreSQL gestionado deja de ser cómodo: quieres una extensión que el nivel no ofrece, quieres ver el plan de consulta real y ajustar work_mem, quieres superusuario. Cuando quieres poseer Postgres — la configuración, la versión, las extensiones, el calendario de copias — un VPS con root completo es la respuesta honesta. Esta es la configuración específica de PostgreSQL; para el cuadro más amplio de «autoalojar una base de datos» (Postgres vs Redis, dónde una máquina compartida es errónea), mira el caso de uso de base de datos general.

Por qué autoalojar PostgreSQL

En tu propia máquina obtienes lo que los niveles gestionados racionan:

• Todo el postgresql.conf — shared_buffers, work_mem, max_connections, ajustes de WAL, adaptados a tu carga, no un valor por defecto del proveedor.
• Cualquier extensión. pgvector para embeddings, PostGIS para geoespacial, TimescaleDB para series temporales, pg_cron, pg_stat_statements — instala lo que necesites. Aquí es donde un nivel gestionado dice no con más frecuencia.
• Tu versión mayor, actualizada en tu calendario, no el del proveedor.
• Superusuario y el SO por debajo — mueve el directorio de datos, ajusta el kernel, ejecuta replicación por streaming a una segunda máquina.

Si pgvector es la razón por la que estás aquí, ten en cuenta que Postgres-más-pgvector es un almacén de vectores completo en una sola máquina — el mismo bloque de construcción detrás de una pila RAG autoalojada y la memoria de agente.

Configúralo (Ubuntu 24.04, Docker)

# docker-compose.yml — PostgreSQL 16 (+ pgvector via the pgvector image)
services:
  db:
    image: pgvector/pgvector:pg16
    restart: always
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: change-me-strong
      POSTGRES_DB: app
    command: ["postgres", "-c", "shared_buffers=512MB", "-c", "work_mem=32MB"]
    volumes: ["/srv/pg:/var/lib/postgresql/data"]
    ports: ["127.0.0.1:5432:5432"]   # localhost only; see below to expose safely

docker compose up -d
docker compose exec db psql -U app -c "CREATE EXTENSION IF NOT EXISTS vector;"

Vinculado a 127.0.0.1, sirve a una app en la misma máquina sin exponer nada. Para dejar entrar a otros servidores, esa es la siguiente sección.

Dejar que otros servidores se conecten — de forma segura

En cuanto otra máquina necesita la base de datos, cambian dos cosas:

1. Una dirección estable y enrutable — un plan con IPv4 dedicada (Small-IP $16, Medium-IP $20). Los planes NAT comparten una IP saliente, bien para saliente pero no para ser una base de datos que otros marcan.
2. Firewall duro. Abre el 5432 solo a las IP de cliente específicas, nunca 0.0.0.0/0, y exige TLS. Un puerto Postgres abierto en la internet pública se encuentra en minutos — bloquéalo con un firewall UFW.

Las copias de seguridad son tu trabajo

Autoalojar significa que las copias corren de tu cuenta, y la regla es: hazlas antes de necesitarlas. pg_dump en cron para copias lógicas, o archivado de WAL para recuperación a un punto en el tiempo en todo lo que te importe. Envía los dumps fuera de la máquina y prueba una restauración al menos una vez — una copia que nunca has restaurado es una esperanza, no una copia. Hay disponible un add-on de copias gestionadas si prefieres no ejecutarlo tú mismo.

Por qué EQVPS para PostgreSQL

• Root completo, superusuario, tu configuración — desde $8/mes, NVMe (RAID1) que importa en cuanto una base de datos y su WAL escriben a la vez.
• Sin KYC, pago en cripto. Email para registrarte, USDC/USDT para pagar.
• UE (Alemania, Finlandia), root en ~60 segundos. Trae tu esquema y adelante.

Caso de uso de base de datos general (panorámica Postgres/Redis) → · RAG autoalojado a escala →