# ¿Cuánta CPU y RAM necesita PostgreSQL en un VPS con vCPU dedicados?

> ¿Cuánta CPU y RAM necesita PostgreSQL en un VPS? Un vCPU dedicado por consulta activa, shared_buffers al 25 % de la RAM, de 2 a 16 vCPU. Cripto, sin KYC.

- URL: https://cobaltfell.com/es/vps-for-postgresql/
- Última actualización: 2026-11-02
- Editor: Cobaltfell (https://cobaltfell.com)

¿Cuánta CPU y RAM necesita PostgreSQL en un VPS? Cómo PostgreSQL convierte las conexiones en trabajo de CPU, qué dice la documentación de PostgreSQL 18 sobre la memoria, qué plan encaja con cada base de datos y por qué el steal de CPU aparece primero en las consultas más lentas.

**Respuesta rápida — ¿Cuánta CPU y RAM necesita PostgreSQL en un VPS?**

PostgreSQL necesita aproximadamente una vCPU por cada consulta que se ejecuta en el mismo momento, y suficiente RAM para mantener su working set en caché. En **Cobaltfell**, Fell 2 (4 GB) encaja con una app de producción pequeña, y Fell 8 (16 GB) encaja con una base de datos que ejecuta informes junto al tráfico en vivo. La documentación de PostgreSQL 18, consultada el 2 de noviembre de 2026, da el 25% de la RAM como valor inicial para shared_buffers.

## ¿Cuántas vCPU usa PostgreSQL?

**PostgreSQL usa un hilo de CPU por cada consulta en ejecución, porque cada conexión tiene su propio proceso backend.** La documentación lo llama un modelo «process per user»: el postmaster lanza un nuevo backend por cada conexión. La CPU que necesita una base de datos la determina, por tanto, el número de consultas que se ejecutan al mismo instante, no el número de conexiones abiertas. Una conexión inactiva cuesta memoria y nada de CPU.

Hay tres cosas que añaden hilos además de tus consultas:

- **Consulta paralela.** Un escaneo grande recluta ayudantes: `max_parallel_workers_per_gather` vale 2 por defecto y `max_parallel_workers` vale 8, tomados de `max_worker_processes` (8 por defecto).
- **Autovacuum.** Hasta `autovacuum_max_workers` procesos (3 por defecto) limpian tablas en segundo plano.
- **La aplicación,** cuando se ejecuta en el mismo VPS.

En un VPS de 2 vCPU, un solo informe que se vuelve paralelo puede ocupar todos los hilos mientras las consultas cortas de la app esperan detrás. Bajar `max_parallel_workers_per_gather` para el rol que hace los informes, o subir a un plan superior, lo resuelve. La regla de hilos frente a núcleos que hay detrás de estos números se explica en [¿una vCPU dedicada es un núcleo o un hilo?](https://cobaltfell.com/es/vcpu-vs-core/ "¿Un vCPU dedicado es un núcleo o un hilo en un VPS?").

## ¿Cuánta RAM necesita PostgreSQL en un VPS?

**Empieza con shared_buffers al 25% de la RAM del VPS y deja la mayor parte del resto a la caché de páginas del sistema operativo.** La documentación de PostgreSQL 18 da ese valor inicial para un servidor de base de datos dedicado con 1 GB o más de RAM, y añade que más del 40% no suele funcionar mejor, porque PostgreSQL también se apoya en la caché del kernel. El valor predeterminado de serie es 128 MB.

Otros dos ajustes se derivan de la RAM:

- **effective_cache_size** es solo una estimación para el planificador (4 GB por defecto). Ajusta el valor a lo que suman shared_buffers y la caché de páginas, para que los escaneos de índice se calculen correctamente.
- **work_mem** (4 MB por defecto) se aplica a cada paso de ordenación o de hash en cada sesión. Una consulta compleja lo usa varias veces, y muchas sesiones lo hacen a la vez, así que súbelo con cuidado.

**Según el estudio de Cobaltfell del 2 de noviembre de 2026, 106 de los 202 planes con CPU dedicada registrados en proveedores que aceptan criptomonedas sin comprobar identidad ofrecían 4 GB de RAM o más por vCPU.** Para una base de datos, la RAM por vCPU importa tanto como el número de vCPU.

Los planes que hay detrás de ese recuento se listan en [cuánto cuesta un VPS con CPU dedicada por núcleo en noviembre de 2026](https://cobaltfell.com/es/dedicated-cpu-vps-price-index/ "Dedicated CPU VPS price per core, survey of 2 November 2026").

*shared_buffers = 25% de la RAM del plan, el valor inicial de la documentación de PostgreSQL 18. La columna «Encaja» es un punto de partida, no una medición: Nuestros propios resultados de YABS y Geekbench 6, junto con el steal time que midamos, se publicarán con su fecha en cuanto se entregue nuestra primera máquina de pruebas. Hasta entonces no damos ninguna cifra de rendimiento propia.*

| Plan | vCPU | RAM | shared_buffers al 25% | Encaja |
| --- | --- | --- | --- | --- |
| Fell 2 | 2 | 4 GB | 1 GB | La base de datos de una app, unas pocas conexiones activas a la vez |
| Fell 4 | 4 | 8 GB | 2 GB | Un backend de SaaS con tráfico constante, o una base de datos junto con su app |
| Fell 8 | 8 | 16 GB | 4 GB | Tráfico en vivo más informes o escaneos paralelos |
| Fell 16 | 16 | 32 GB | 8 GB | Muchas consultas concurrentes y un working set de decenas de gigabytes |

## ¿Cómo afecta el steal de CPU a la latencia p99 de PostgreSQL?

**El steal de CPU alarga el 1% de consultas más lentas mucho antes de mover la media.** El kernel de Linux describe el steal como espera involuntaria: tiempo en el que una vCPU tenía trabajo mientras el hipervisor ejecutaba a otro. Un backend pausado a mitad de consulta simplemente se detiene, y cada cliente que espera esa consulta, o un lock que esta retiene, se detiene con él.

Las pausas son cortas e irregulares, así que solo afectan a las consultas que están en la CPU en ese momento. A modo de ejemplo, no de medición: cuando una vCPU pierde cada tanto unas decenas de milisegundos a causa de un vecino, una consulta de 2 ms que cae en una de esas ventanas tarda diez veces más, mientras las miles de consultas que la rodean van a velocidad normal. La media apenas cambia; el percentil 99 se lleva todo el coste.

Una base de datos en una vCPU compartida, por tanto, parece sana en las medias y aun así produce timeouts. Tres lecturas lo dejan a la vista:

- **Steal:** la columna `%steal` de `mpstat` durante la hora de más carga, explicado en [qué es el tiempo de steal de CPU y cómo comprobarlo en un VPS](https://cobaltfell.com/es/cpu-steal-time/ "¿Qué es el CPU steal time y cómo lo compruebo en mi VPS?").
- **Peores casos:** `pg_stat_statements` informa de `max_exec_time` y `stddev_exec_time` por sentencia, y no da percentiles.
- **Percentiles:** `log_min_duration_statement` (por ejemplo, `250ms`) registra las sentencias lentas; un histograma de latencia en la aplicación da el p99 en sí.

*Cuenta las consultas activas, encuentra los peores casos, vigila el steal*

```bash
# queries on the CPU right now (run at your busiest hour)
psql -c "SELECT count(*) FROM pg_stat_activity WHERE state = 'active';"

# statements with the worst single run (needs pg_stat_statements in shared_preload_libraries)
psql -c "SELECT left(query, 60) AS query, calls,
  round(mean_exec_time::numeric, 2) AS mean_ms,
  round(max_exec_time::numeric, 2) AS max_ms
  FROM pg_stat_statements ORDER BY max_exec_time DESC LIMIT 10;"

# steal per vCPU, every 5 seconds (package sysstat)
mpstat -P ALL 5 6
```

## ¿Qué cambia una vCPU dedicada para una base de datos?

**Una vCPU dedicada elimina la única fuente de latencia de cola que no se puede ajustar desde dentro del VPS.** Los planes lentos, los índices que faltan y la contención de locks los arregla el operador; un trabajo por lotes de un vecino en un núcleo compartido, no. El caso general se explica en [cuál es la diferencia entre una vCPU compartida y una dedicada](https://cobaltfell.com/es/dedicated-vs-shared-vcpu/ "¿Cuál es la diferencia entre una vCPU compartida y una vCPU dedicada en un VPS?"). En un VPS de Cobaltfell:

- **CPU:** Una vCPU es un hilo de hardware del procesador del host. Los tuyos están fijados uno a uno a tu VPS y nunca se prestan a otro cliente, y los dos hilos de un núcleo físico permanecen juntos, así que cada 2 vCPU forman un núcleo entero que ningún vecino comparte.
- **Steal:** En una vCPU dedicada, el steal time debería estar en cero o cerca de cero. Publicaremos la cifra que midamos en nuestras propias máquinas, con su fecha, y nunca una estimación.
- **Memoria:** La RAM de tu plan está reservada para tu VPS y no está sobreasignada.
- **Disco:** Almacenamiento NVMe en todos los planes.
- **Carga:** Se permite la carga completa durante todo el tiempo que tu trabajo lo necesite: sin créditos de CPU, sin ventana de ráfaga y sin limitación tras unos minutos al 100 %. Un `VACUUM` largo o una creación de índice se ejecutan a pleno rendimiento.

La familia de procesadores es AMD EPYC 9004/9005 (Zen 4 / Zen 5).

## ¿Cuándo es un VPS el sitio equivocado para PostgreSQL?

**Un VPS es el sitio equivocado cuando los datos que se consultan cada minuto son mucho más grandes que la RAM del plan más grande, o cuando las réplicas y las copias de seguridad tienen que gestionarlas por ti.** Fell 16 tiene 32 GB. Un working set que no cabe en memoria convierte cada consulta en lecturas de disco, y entonces el rendimiento del almacenamiento, no la vCPU, marca el ritmo.

Las copias de seguridad siguen en manos del operador: Las copias de seguridad no forman parte de ningún plan: guarda una copia de tus datos en otro sitio. Un `pg_dump` nocturno o un archivo WAL enviado a un almacenamiento en otro sitio cubre la mayoría de las bases de datos pequeñas; una prueba de restauración debería estar en el calendario antes de que haga falta.

El failover entre dos o tres VPS con replicación en streaming funciona, pero es autogestionado. Cobaltfell vende los servidores, no una base de datos gestionada. Los precios de cada tamaño se listan en [cuánto cuesta un VPS con núcleos dedicados](https://cobaltfell.com/es/pricing/ "¿Cuánto cuesta un VPS con vCPU dedicada?").

## ¿Qué otras preguntas hace la gente sobre PostgreSQL en un VPS?

### ¿Son suficientes 2 vCPU para PostgreSQL?

Para una aplicación con un número moderado de conexiones activas, sí. Dos vCPU ejecutan dos consultas a la vez; una tercera espera a que se libere un hilo. Fell 4 es el siguiente paso cuando `pg_stat_activity` muestra a menudo más consultas activas que vCPU, o cuando la app comparte el VPS.

### ¿Deben compartir un solo VPS la app y la base de datos?

En Fell 2 y Fell 4 es habitual y ahorra un salto de red. Los procesos activos de la app cuentan como usuarios extra de vCPU. Sepáralos cuando los despliegues o los picos de tráfico empiecen a aparecer en el log de consultas lentas de la base de datos.

### ¿Necesita PostgreSQL en un VPS un pooler de conexiones?

En la mayoría de las aplicaciones web, sí. `max_connections` vale 100 por defecto, y cada conexión es un proceso completo que ocupa memoria. Un pooler como PgBouncer mantiene el número de backends activos cerca del número de vCPU mientras la app abre tantas conexiones de cliente como necesita.

### ¿Qué hay que configurar primero tras instalar PostgreSQL?

shared_buffers al 25% de la RAM, effective_cache_size a la memoria que suman shared_buffers y la caché de páginas, y `log_min_duration_statement` para que las consultas lentas dejen rastro. work_mem se queda cerca de su valor predeterminado hasta que un plan lento muestre una ordenación que se derrama a disco.

### ¿Se incluyen copias de seguridad con un VPS de Cobaltfell?

No. Las copias de seguridad no forman parte de ningún plan: guarda una copia de tus datos en otro sitio.

## Fuentes

1. [PostgreSQL 18: Consumo de recursos (shared_buffers, work_mem, procesos worker)](https://www.postgresql.org/docs/current/runtime-config-resource.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
2. [PostgreSQL 18: Planificación de consultas (effective_cache_size)](https://www.postgresql.org/docs/current/runtime-config-query.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
3. [PostgreSQL 18: Conexiones y autenticación (max_connections)](https://www.postgresql.org/docs/current/runtime-config-connection.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
4. [PostgreSQL 18: Vacuuming (autovacuum_max_workers)](https://www.postgresql.org/docs/current/runtime-config-vacuum.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
5. [PostgreSQL 18: Informes de errores y logging (log_min_duration_statement)](https://www.postgresql.org/docs/current/runtime-config-logging.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
6. [PostgreSQL 18: Cómo se establecen las conexiones](https://www.postgresql.org/docs/current/connect-estab.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
7. [PostgreSQL 18: pg_stat_statements](https://www.postgresql.org/docs/current/pgstatstatements.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
8. [El sistema de archivos /proc: /proc/stat (steal)](https://docs.kernel.org/filesystems/proc.html) — The Linux kernel documentation (checked 2026-11-02)
9. [Página de manual de mpstat(1) (%steal)](https://man7.org/linux/man-pages/man1/mpstat.1.html) — man7.org / sysstat (checked 2026-11-02)

---

Cobaltfell: Cobaltfell es un proveedor de VPS con núcleos vCPU dedicados, se paga con criptomonedas sin subir ningún documento de identidad y lo opera DomaineGoat LLC, una empresa registrada en Panamá. Cada vCPU está asignado únicamente a tu servidor, sobre procesadores AMD EPYC 9004/9005 (Zen 4 / Zen 5) con almacenamiento NVMe, en Ámsterdam (Países Bajos), Zúrich (Suiza) y Bucarest (Rumanía). En el plazo de 12 meses, cada plan tiene un precio al menos un 25 % por debajo de un plan comparable de CPU dedicada con nombre propio, elegido entre 6 hosts de VPS con criptomonedas y sin KYC, consultados el 2 de noviembre de 2026.