Cómo instalar PostgreSQL con pgvector paso a paso

Probado con PostgreSQL 18.6 · pgvector 0.8.6 · PGDG APT · Docker · verificado 2026-09-16

Actualizado: 2026-09-16

Montar PostgreSQL^[1] con pgvector^[2] es la forma más sensata de arrancar un proyecto RAG sin introducir una base de datos nueva en el stack. Esta guía describe una instalación reproducible de PostgreSQL 18.6 y pgvector 0.8.6 sobre Debian 12 y 13 o Ubuntu 22.04, 24.04 y 26.04, con una alternativa en Docker. Justifica cada decisión y opera con las mismas herramientas que ya dominamos: pg_dump, pg_basebackup, pg_stat_statements y réplicas.

Qué ha cambiado desde pgvector 0.6 y PostgreSQL 16

Esta guía se escribió en febrero de 2024 sobre PostgreSQL 16 y pgvector 0.6. La revisé el 16 de septiembre de 2026: repetí todos los pasos en Debian 13 y los de instalación en Ubuntu 24.04, ambos en contenedores arm64. La versión actual de pgvector es la 0.8.6, del 29 de julio de 2026 (CHANGELOG^[3]), y la de PostgreSQL, la 18.6, publicada el 13 de agosto de 2026 (anuncio^[4]). La 16 sigue soportada hasta el 9 de noviembre de 2028 según la política de versiones^[5], y la 19 está en beta 3.

Los pasos usan ahora PostgreSQL 18. PGDG publica postgresql-18 18.6 y postgresql-18-pgvector 0.8.6 para Debian 12 y 13 y para Ubuntu 22.04, 24.04 y 26.04, en amd64 y arm64; lo comprobé en los índices del repositorio. Si te quedas en la 16, cambia el número en los nombres de paquete. Esto es lo que ha cambiado:

• Tipos nuevos (0.7.0, abril de 2024): halfvec (media precisión, hasta 4.000 dimensiones indexables), sparsevec (vectores dispersos) e indexación del tipo bit, junto con binary_quantize, subvector, l2_normalize, y las distancias L1, Hamming y Jaccard. Un índice HNSW sobre (embedding::halfvec(1536)) halfvec_l2_ops ocupa la mitad.
• Exploración iterativa de índices (0.8.0, octubre de 2024): afecta directamente a la consulta con WHERE tenant_id de esta guía. Con índices aproximados el filtro se aplica después de recorrer el índice, así que una condición selectiva puede devolver menos filas de las pedidas. SET hnsw.iterative_scan = relaxed_order (o strict_order, y ivfflat.iterative_scan para IVFFlat) hace que el índice siga explorando hasta reunir resultados suficientes. La 0.8.0 también mejoró la estimación de coste para que el planificador elija mejor entre índice y filtro, y retiró el soporte de PostgreSQL 12.
• Fallo de seguridad CVE-2026-3172 (0.8.2, 25 de febrero de 2026): un desbordamiento de búfer en la construcción paralela de índices HNSW permite a un usuario que pueda crear o reindexar un índice leer datos de otras relaciones o tumbar el servidor. Afecta de la 0.6.0 a la 0.8.1, según el aviso del proyecto^[6].
• PostgreSQL 18: soporte desde la 0.8.1 (septiembre de 2025); la 0.8.2 arregló la salida de EXPLAIN y la 0.8.3 una regresión de rendimiento de Hamming y Jaccard sobre la 18.
• Correcciones de 2026 que importan en producción: la 0.8.3 (17 de junio) arregló una posible corrupción del índice HNSW durante el VACUUM, y la 0.8.4 (30 de junio), el error «hnsw graph not repaired» y un posible error de las inserciones durante ese mismo vacuum. La 0.8.4 también evitó que las construcciones IVFFlat superasen maintenance_work_mem, y la 0.8.5 redujo su memoria con tablas pequeñas. La 0.8.6 corrige un desbordamiento de búfer de IVFFlat en sistemas de 32 bits y la memoria de sus recorridos en nested loops. Si vienes de la 0.6, actualiza el paquete y ejecuta ALTER EXTENSION vector UPDATE; en cada base.
• Cambios de PostgreSQL 18 que tocan esta guía: initdb activa por defecto las sumas de verificación de datos (data checksums), y pg_upgrade exige que coincidan entre clústeres, como se ve en las preguntas frecuentes. La imagen Docker, además, guarda los datos en /var/lib/postgresql/18/docker y monta el volumen en /var/lib/postgresql.

Por qué pgvector y no una base vectorial dedicada

La tentación de elegir Pinecone, Weaviate, Milvus o Qdrant es natural cuando uno empieza a leer sobre embeddings. Todas son soluciones competentes, pero introducen un sistema nuevo que hay que desplegar, respaldar, monitorizar y aprender. Si tus consultas mezclan búsqueda semántica y filtros relacionales, y el índice cabe en la memoria del servidor, pgvector suele ser la decisión económicamente correcta.

La contrapartida honesta: pgvector no compite en rendimiento puro con motores escritos expresamente para vectores, ni en funciones como la cuantización por producto. Tampoco filtra dentro del grafo del índice, sino después de recorrerlo. Si la aplicación vive y muere por la latencia sobre cientos de millones de documentos, conviene reevaluar. Por debajo de ese umbral, tener un único sistema que el equipo sabe operar paga dividendos cada vez que toca restaurar un backup a las tres de la mañana.

Para el análisis de cuándo escalar a una base dedicada y cómo se comporta pgvector con HNSW en producción, ver pgvector en 2024: HNSW y escalado real.

Paso 1: repositorio oficial PGDG

Las versiones de PostgreSQL de las distribuciones van por detrás de la rama estable, y con pgvector la diferencia importa. Ubuntu 24.04 ofrece en universe postgresql-16-pgvector 0.6.0 y Debian 13 trae postgresql-17-pgvector 0.8.0, dos versiones dentro del rango de CVE-2026-3172. El rastreador de seguridad de Debian^[7] marca la de trixie como vulnerable y el de Ubuntu^[8] tiene la de noble pendiente de evaluar.

El repositorio PGDG del propio proyecto trae PostgreSQL 18.6 y pgvector 0.8.6. Esta es la configuración manual que documenta la wiki de PGDG^[9], con el fichero de fuentes en formato deb822:

sudo apt install -y curl ca-certificates
sudo install -d /usr/share/postgresql-common/pgdg
sudo curl -o /usr/share/postgresql-common/pgdg/apt.postgresql.org.asc \
  --fail https://www.postgresql.org/media/keys/ACCC4CF8.asc

. /etc/os-release
sudo tee /etc/apt/sources.list.d/pgdg.sources <<EOF
Types: deb
URIs: https://apt.postgresql.org/pub/repos/apt
Suites: $VERSION_CODENAME-pgdg
Architectures: $(dpkg --print-architecture)
Components: main
Signed-By: /usr/share/postgresql-common/pgdg/apt.postgresql.org.asc
EOF

sudo apt update
sudo apt install -y postgresql-18

El bloque guarda la clave del repositorio, genera el fichero de fuentes con el nombre en clave de tu distribución (trixie, bookworm, noble…) y tu arquitectura, e instala el servidor. La versión anterior de esta guía usaba lsb_release, que no está en la imagen debian:trixie, y un echo partido en dos líneas con el que APT responde E: Malformed entry 1. Si prefieres un script, la wiki ofrece sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh tras instalar postgresql-common; sin la opción -y se detiene a pedir que pulses Intro.

En un servidor con systemd, el clúster arranca solo como postgresql@18-main.service. En mis contenedores, sin systemd, pg_lsclusters mostraba 18 main parado en /var/lib/postgresql/18/main, y lo arranqué con sudo pg_ctlcluster 18 main start.

Paso 2: instalar pgvector

El paquete postgresql-18-pgvector de PGDG trae la última versión publicada. Comprueba la candidata e instálalo:

apt-cache policy postgresql-18-pgvector
sudo apt install -y postgresql-18-pgvector

En Debian 13, apt-cache policy devolvió esto; en Ubuntu 24.04, la candidata fue 0.8.6-1.pgdg24.04+1:

postgresql-18-pgvector:
  Installed: (none)
  Candidate: 0.8.6-1.pgdg13+1

PGDG conserva las tres últimas versiones de cada paquete desde el 23 de abril de 2026, así que puedes fijar una concreta con sudo apt install postgresql-18-pgvector=0.8.6-1.pgdg13+1.

Si necesitas compilar desde el código fuente, por ejemplo para aplicar un parche, instala antes las herramientas de compilación y las cabeceras del servidor:

sudo apt install -y build-essential git postgresql-server-dev-18
git clone --branch v0.8.6 https://github.com/pgvector/pgvector.git
cd pgvector
make
sudo make install

Sin esas dependencias, el primer make falla con make: command not found. postgresql-server-dev-18 instala también clang-19, que el make usa para generar el bitcode del compilador JIT de PostgreSQL.

A diferencia de otras extensiones, pgvector no requiere shared_preload_libraries. La extensión es por base de datos, no global al clúster.

Alternativa: pgvector en Docker con PostgreSQL 18

Si prefieres contenedores, la imagen pgvector/pgvector añade la extensión a la imagen oficial de PostgreSQL. La etiqueta 0.8.6-pg18-trixie apunta al mismo digest que pg18-trixie (actualizadas el 13 de agosto de 2026 en Docker Hub). Este es el compose.yaml que usé:

services:
  db:
    image: pgvector/pgvector:0.8.6-pg18-trixie
    restart: unless-stopped
    shm_size: 1g
    environment:
      POSTGRES_USER: ragapp
      POSTGRES_PASSWORD: contraseña_fuerte_aquí
      POSTGRES_DB: ragdb
    volumes:
      - pgdata:/var/lib/postgresql
    ports:
      - "127.0.0.1:5432:5432"

volumes:
  pgdata:

Fíjate en el volumen. Desde PostgreSQL 18, la imagen guarda los datos en /var/lib/postgresql/18/docker y declara el volumen en /var/lib/postgresql, no en /var/lib/postgresql/data (cambio de la imagen oficial^[10]). Si reutilizas un compose antiguo con la ruta vieja, el contenedor no arranca: en mi prueba salió con código 1 y este mensaje:

Error: in 18+, these Docker images are configured to store database data in a
       format which is compatible with "pg_ctlcluster" (specifically, using
       major-version-specific directory names).

shm_size también importa. Con los 64 MB de /dev/shm que Docker asigna por defecto y maintenance_work_mem en 2 GB, una construcción HNSW paralela falló con could not resize shared memory segment y No space left on device. Con 4 GB terminó sin error, y la documentación de pgvector pide que ese tamaño sea al menos igual a maintenance_work_mem.

Con esta configuración, SHOW data_directory devolvió /var/lib/postgresql/18/docker, y una tabla de prueba sobrevivió a docker compose down y up -d. En la imagen, POSTGRES_USER es superusuario, así que ragapp puede crear la extensión por sí mismo; si quieres un rol de aplicación sin privilegios, créalo aparte como en el paso 3. Para el resto de detalles, consulta cómo instalar PostgreSQL con Docker.

Paso 3: usuario, base de datos y extensión

Nunca uses el rol postgres para la aplicación. Crea un rol dedicado desde sudo -u postgres psql:

-- Conectar como postgres
CREATE ROLE ragapp WITH LOGIN PASSWORD 'contraseña_fuerte_aquí';
CREATE DATABASE ragdb OWNER ragapp;

-- Conectar a ragdb
\c ragdb
CREATE EXTENSION IF NOT EXISTS vector;

-- Verificar instalación
SELECT extname, extversion FROM pg_extension WHERE extname = 'vector';

En PostgreSQL 18.6 con pgvector 0.8.6, la verificación devolvió:

 extname | extversion
---------+------------
 vector  | 0.8.6
(1 row)

La consulta a pg_extension es la primera verificación de que binario y catálogo están en línea. La extensión la crea postgres porque pgvector no está marcada como trusted: cuando lo intenté como ragapp, PostgreSQL respondió permission denied to create extension "vector", con la pista Must be superuser to create this extension.

La versión anterior de esta guía añadía GRANT ALL ON SCHEMA public TO ragapp, que ya sobra. Desde PostgreSQL 15 el esquema public pertenece a pg_database_owner (notas de la versión 15^[11]), así que el propietario de ragdb puede crear tablas en él: lo comprobé como ragapp sin ese GRANT.

Paso 4: configuración mínima de producción

Los valores por defecto de PostgreSQL son conservadores: la 18 arranca con shared_buffers = 128MB. Para una máquina con 16 GB dedicados a la base, deja tus ajustes en un fichero de conf.d, que el postgresql.conf de Debian y Ubuntu incluye con include_dir:

sudo tee /etc/postgresql/18/main/conf.d/ragdb.conf <<'EOF'
shared_buffers = 4GB
effective_cache_size = 12GB
work_mem = 64MB
maintenance_work_mem = 512MB
wal_level = replica
max_wal_size = 4GB
max_connections = 100
EOF
sudo pg_ctlcluster 18 main restart

Ejecutado como root, pg_ctlcluster delega en systemctl cuando hay systemd, según su página de manual^[12]. Tras el reinicio, SHOW shared_buffers; devolvió 4GB y SHOW maintenance_work_mem;, 512MB.

La regla práctica sitúa shared_buffers cerca del 25% de la memoria y effective_cache_size en torno al 75%. work_mem moderado porque se multiplica por conexiones y por operaciones dentro de cada consulta: 64 MB × 100 conexiones × 2 operaciones son 12 GB teóricos, así que mide antes de subirlo.

maintenance_work_mem importa especialmente porque CREATE INDEX sobre HNSW lo consume generosamente. Si el grafo no cabe, pgvector avisa con hnsw graph no longer fits into maintenance_work_mem y, según su documentación, la construcción tarda bastante más. Para una carga grande, súbelo solo en la sesión que construye el índice con SET maintenance_work_mem = '2GB';.

La documentación de pgvector también sugiere subir max_parallel_maintenance_workers (2 por defecto) para construir en paralelo. En mi prueba con 99.000 embeddings no bastó, porque los vectores viven en TOAST y la tabla principal ocupaba 7 MB. La construcción no pidió memoria compartida para procesos paralelos hasta fijar ALTER TABLE documents SET (parallel_workers = 4) en esa tabla.

Paso 5: IVFFlat o HNSW

pgvector ofrece dos estructuras de índice aproximado, y las medí con 99.000 embeddings reales de 1536 dimensiones:

IVFFlat: más antiguo, particiona el espacio en listas mediante k-means al construir el índice, así que créalo después de cargar datos representativos. Consume menos memoria y se construye antes: con cuatro procesos paralelos tardó 4,3 s, frente a 23,0 s de HNSW. La máquina tenía 18 núcleos y una carga media de entre 3,5 y 4,3.

HNSW: incorporado en la versión 0.5.0 (agosto de 2023), construye un grafo jerárquico con mejor relación precisión-latencia. No tiene fase de entrenamiento, así que puede crearse con la tabla vacía. En la misma prueba dio un 95,1 % de recall@10 con 1,15 ms de mediana, frente al 92,8 % y 8,7 ms de IVFFlat con lists = 100 y probes = 10.

La recomendación, en 2024 y también en 2026, es empezar con HNSW con los parámetros por defecto (m = 16, ef_construction = 64). Si el dataset supera decenas de millones de filas o la ventana de mantenimiento es estrecha, IVFFlat puede ser más apropiado. Dale a lists el valor de filas / 1000 hasta un millón de filas y la raíz cuadrada de las filas por encima. La tabla completa de la medición está en pgvector: búsqueda semántica sin salir de Postgres.

Paso 6: esquema típico y operadores de distancia

Un esquema canónico para RAG, con un índice B-tree para el filtro por tenant:

CREATE TABLE docs (
    id          bigserial PRIMARY KEY,
    tenant_id   integer NOT NULL,
    content     text,
    metadata    jsonb,
    embedding   vector(1536)  -- text-embedding-3-small
);

-- B-tree para el filtro por tenant, GIN para los metadatos
CREATE INDEX ON docs (tenant_id);
CREATE INDEX ON docs USING gin (metadata);

-- HNSW para la búsqueda vectorial
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

La dimensión depende del modelo: text-embedding-3-small de OpenAI devuelve 1536 por defecto. Para búsquedas:

SET hnsw.ef_search = 100;
SET hnsw.iterative_scan = relaxed_order;

-- Búsqueda semántica con filtro por tenant
SELECT id, content, embedding <=> $1 AS distance
FROM docs
WHERE tenant_id = $2
ORDER BY embedding <=> $1
LIMIT 10;

relaxed_order importa aquí. La probé con 20.000 filas repartidas entre 10 tenants, sin el índice B-tree y con el HNSW forzado. Sin recorrido iterativo devolvió 4 filas de 10 con ef_search = 40 y 9 con ef_search = 100; con relaxed_order, las 10. Ese modo puede devolver filas ligeramente desordenadas por distancia, así que usa strict_order si el orden exacto importa.

Los operadores habituales son tres: <=> para coseno, <-> para euclídea y <#> para producto interno negado; la 0.7.0 añadió <+> (L1) y, para vectores bit, <~> y <%>. Con modelos OpenAI, que devuelven vectores normalizados, usa coseno. Mezclar operadores con vectores no normalizados es la fuente más frecuente de resultados extraños que luego se achacan al índice.

Logotipo de PostgreSQL (Imagen: Daniel Lundin, BSD, vía Wikimedia Commons)

Paso 7: acceso, backup y observabilidad

Acceso remoto: por defecto el servidor escucha en localhost. Si la aplicación reside en otro nodo, abre listen_addresses a la interfaz privada y añade una línea en pg_hba.conf que limite el rango y exija scram-sha-256. Nunca expongas PostgreSQL directamente a Internet.

Backup: pg_dump -Fc -Z9 sirve el día uno. Cuando la base crezca, adopta pgbackrest o restic con rotaciones incrementales y prueba la restauración periódicamente. Un backup sin prueba de restore es una expectativa, no una garantía.

Observabilidad mínima:

-- Habilitar estadísticas de queries
ALTER SYSTEM SET shared_preload_libraries = 'pg_stat_statements';
-- Reiniciar y luego:
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Exportar métricas con postgres_exporter^[13] hacia Prometheus. Vigilar tres señales clave:

• Buffer cache hit ratio: debe superar el 99%. Si HNSW se sale de RAM, el rendimiento cae en acantilado.

• pg_stat_user_indexes.idx_scan: confirma que el índice HNSW se está usando efectivamente.

• Recall: compara de vez en cuando los resultados del índice con los de la búsqueda exacta (SET LOCAL enable_indexscan = off dentro de una transacción), como propone la documentación de pgvector.

Con HNSW, el VACUUM tiene que reparar el grafo tras borrados y actualizaciones, y la documentación de pgvector avisa de que puede tardar. Si tarda, reindexa primero y lanza el VACUUM después:

REINDEX INDEX CONCURRENTLY docs_embedding_idx;
VACUUM docs;

La 0.8.3 corrigió en ese VACUUM una posible corrupción del índice, y la 0.8.4, el error «hnsw graph not repaired». No te quedes por debajo de la 0.8.4.

Para la perspectiva de observabilidad más amplia con stacks modernos, ver Grafana y observabilidad stack o OpenTelemetry para unificación.

Verificación final

Comprueba que todo funciona con un vector de prueba:

-- Insertar un vector de prueba (1536 dims con valores aleatorios)
INSERT INTO docs (tenant_id, content, embedding)
VALUES (1, 'Documento de prueba',
        (SELECT array_agg(random())::vector(1536)
         FROM generate_series(1, 1536)));

-- Búsqueda vectorial básica
SELECT id, content FROM docs
ORDER BY embedding <=> (SELECT embedding FROM docs LIMIT 1)
LIMIT 5;

Si la consulta devuelve el documento sin error y el plan muestra el índice HNSW, la instalación es correcta. Antepón EXPLAIN (COSTS OFF) a la búsqueda para ver el plan; este es el que obtuve en PostgreSQL 18.6, con una sola fila en la tabla:

 Limit
   InitPlan 1
     ->  Limit
           ->  Seq Scan on docs docs_1
   ->  Index Scan using docs_embedding_idx on docs
         Order By: (embedding <=> (InitPlan 1).col1)

Preguntas frecuentes

¿pgvector funciona con réplicas de solo lectura y pg_basebackup?

Sí. pgvector escribe en el WAL, así que se replica igual que cualquier otra tabla o índice y admite recuperación a un punto en el tiempo. Una réplica física creada con pg_basebackup incluye el índice HNSW o IVFFlat sin pasos adicionales. Aun así, asegúrate de que la réplica tiene instalado el paquete postgresql-18-pgvector (o el de tu versión): el binario de la extensión queda fuera del stream de WAL.

¿Hay que reconstruir el índice HNSW al actualizar de versión de PostgreSQL?

No con pg_upgrade en modo --link: lo comprobé de 16.15 a 18.6 con pgvector 0.8.6 y pg_upgradecluster -m link, y el fichero del índice HNSW conservó su inodo y siguió en uso. Instala antes postgresql-18-pgvector; si trae una versión más nueva, pg_upgrade lo avisa y genera un script para actualizar la extensión. Como la 18 activa las sumas de verificación por defecto, un pg_upgrade --check contra un clúster 16 sin ellas falló con old cluster does not use data checksums but the new one does, mientras que pg_upgradecluster creó el clúster nuevo sin ellas y terminó sin error. Un pg_dump/pg_restore, en cambio, reconstruye HNSW desde cero, lo que puede tardar según el volumen de vectores y el maintenance_work_mem disponible.

¿Cuántos vectores soporta pgvector antes de que compense migrar a una base dedicada?

No hay un número mágico: depende del patrón de consulta, del margen de latencia y de si el índice cabe en memoria. Como referencia, el índice HNSW de 99.000 vectores de 1536 dimensiones ocupó 773 MB en mi prueba, unos 7,6 GB por millón de vectores. Si esa cifra no cabe en la RAM del servidor, prueba antes halfvec o la cuantización binaria con re-ranking, que la documentación de pgvector propone para escalar.

¿Puedo tener varias columnas vector con dimensiones distintas en la misma tabla?

Sí. vector(n) fija la dimensión por columna, no por tabla ni por base de datos. Puedes tener una columna para los embeddings de un modelo y otra para un modelo distinto, cada una con su propio índice HNSW o IVFFlat. Si necesitas dimensiones distintas en la misma columna, declárala como vector sin tamaño e indexa cada dimensión con un índice parcial por expresión, como explica la documentación de pgvector.

¿pgvector tiene coste de licencia sobre PostgreSQL?

No. pgvector se distribuye bajo la licencia de PostgreSQL, un permiso equivalente a BSD/MIT, igual que el propio motor. No hay coste de licencia; el único coste real es operativo: CPU, memoria y almacenamiento para construir y mantener los índices.

Conclusión

Instalar PostgreSQL con pgvector no es complicado, pero cada decisión importa más de lo que parece. Cinco decisiones marcan la diferencia entre un despliegue que envejece bien y uno que exige intervención cada pocas semanas. Son el repositorio PGDG con una versión igual o posterior a la 0.8.4, el rol dedicado, la extensión creada en la base correcta y el índice HNSW construido en el momento adecuado. La quinta es un maintenance_work_mem suficiente para que esa construcción no se eternice.

El argumento para usar pgvector frente a alternativas dedicadas es operativo más que técnico. Pocas organizaciones se benefician de introducir una base específica para vectores cuando ya operan PostgreSQL con soltura. El ahorro aparente en rendimiento se paga con creces en complejidad de backup, réplicas y monitorización duplicadas. Cuando llegue el momento de migrar a un motor especializado, el punto de partida será una base ya en producción, y eso hace que postergar la migración sea casi siempre la decisión correcta.

Este artículo también está disponible en inglés: How to Install PostgreSQL with pgvector Step by Step.

Fuentes:

1. PostgreSQL 18 — Documentación oficial^[14]
2. pgvector — Repositorio en GitHub^[2]
3. pgvector — Registro de cambios^[3]
4. pgvector — Aviso de CVE-2026-3172^[6]
5. PGDG — Repositorio APT oficial de PostgreSQL^[9]
6. PostgreSQL — Notas de la versión 18^[15]
7. PostgreSQL — Documentación de pg_upgrade^[16]
8. docker-library/postgres — Nuevo PGDATA en PostgreSQL 18^[10]
9. Debian — Estado de CVE-2026-3172^[7]
10. Ubuntu — Estado de CVE-2026-3172^[8]
11. postgres_exporter — Prometheus Community^[13]

Fuentes

1. PostgreSQL
2. pgvector
3. CHANGELOG
4. anuncio
5. política de versiones
6. aviso del proyecto
7. rastreador de seguridad de Debian
8. Ubuntu
9. wiki de PGDG
10. cambio de la imagen oficial
11. notas de la versión 15
12. página de manual
13. postgres_exporter
14. PostgreSQL 18 — Documentación oficial
15. PostgreSQL — Notas de la versión 18
16. PostgreSQL — Documentación de pg_upgrade

Ruta: LLMs en local: ejecuta modelos en tu hardware