Publicado el 04 de agosto de 2026 · Revisado el 04 de agosto de 2026
Cómo instalar y configurar PostgreSQL en tu VPS, paso a paso
Casi cualquier aplicación real —desde un backend propio hasta lo que instalaste con Docker o n8n en guías anteriores— necesita una base de datos donde guardar información de forma persistente. Esta guía instala PostgreSQL desde cero en un VPS, lo asegura para que no quede expuesto a internet por accidente, y crea la primera base de datos y usuario para tu aplicación.
Si ya instalaste Nginx, Docker o alguna app propia en tu VPS, tarde o temprano vas a necesitar un lugar donde esa aplicación guarde datos de forma persistente — usuarios, pedidos, configuración, lo que sea. PostgreSQL es una de las bases de datos más usadas para esto: robusta, gratuita, y con dos décadas de uso en producción real. Vamos a instalarla y dejarla lista para tu primera aplicación.
Actualiza el sistema antes de instalar nada:
sudo apt update && sudo apt upgrade -y
Instala PostgreSQL junto con el paquete de extensiones adicionales que la mayoría de las instalaciones terminan necesitando tarde o temprano:
sudo apt install -y postgresql postgresql-contrib
Verifica que el servicio quedó activo:
sudo systemctl status postgresql
Deberías ver active (running). Si no arrancó solo, actívalo con sudo systemctl enable --now postgresql.
Entiende cómo funciona la autenticación por defecto antes de seguir. PostgreSQL crea automáticamente un usuario del sistema operativo llamado postgres, que es también el superusuario de la base de datos. Por defecto, solo puedes conectarte como ese usuario si estás loggeado como el mismo usuario postgres en el servidor — es una capa de seguridad razonable para empezar, pero significa que tu aplicación no debería usar directamente esta cuenta.
Entra a la consola de PostgreSQL como el usuario del sistema postgres:
sudo -u postgres psql
Crea un usuario específico para tu aplicación, con su propia contraseña, en vez de usar el superusuario para todo. Esto es lo que en seguridad se llama principio de mínimo privilegio: si algún día tu aplicación se ve comprometida, el atacante hereda solo los permisos de este usuario limitado, no control total sobre toda la base de datos del servidor:
CREATE USER appuser WITH PASSWORD 'una-contraseña-fuerte-aquí';
Crea la base de datos para tu aplicación, asignándola como propietario a ese usuario recién creado:
CREATE DATABASE appdb OWNER appuser;
Sal de la consola con \q.
Prueba que el nuevo usuario puede conectarse a su base de datos:
psql -U appuser -d appdb -h localhost
Te va a pedir la contraseña que definiste. Si entras sin error, la base y el usuario están funcionando correctamente.
No expongas PostgreSQL a internet a menos que tengas una razón real y sepas exactamente por qué. Por defecto, PostgreSQL en Ubuntu/Debian escucha solo en localhost — solo aplicaciones corriendo en el mismo servidor pueden conectarse. Eso es lo correcto para la gran mayoría de los casos: tu aplicación y tu base de datos viven en el mismo VPS, y no hay ninguna razón para que el puerto 5432 sea alcanzable desde fuera. Si en tu caso específico necesitas que otro servidor se conecte de forma remota, hazlo a través de una VPN o una conexión SSH en túnel, nunca abriendo el puerto directamente al internet público — una base de datos expuesta sin ese cuidado es uno de los objetivos más buscados por escaneos automatizados de atacantes.
Antes de poner cualquier dato real en producción, arma un respaldo básico. El comando más simple para exportar una base completa es:
pg_dump -U appuser -d appdb -h localhost -f respaldo.sql
Correr esto manualmente sirve para probar que funciona, pero para producción real conviene automatizarlo con una tarea programada (cron) que lo corra a diario y guarde el archivo en un lugar distinto al propio servidor — un respaldo que vive en el mismo disco que puede fallar no es un respaldo confiable.
Una base de datos con tráfico real —muchas conexiones simultáneas, consultas complejas, un volumen de datos que crece— consume RAM y CPU de forma mucho más exigente que servir páginas estáticas. Si tu aplicación ya depende de esto en producción, no de una prueba, en /planes/vds tienes los recursos dedicados para que la base de datos no se convierta en el cuello de botella de todo tu proyecto.
Artículos relacionados
03 de ago de 2026
Qué es AnythingLLM y cómo instalarlo en tu servidor para chatear con tus documentos usando tu propio modelo
02 de ago de 2026
Cómo revisar cuánto espacio y recursos está usando tu cuenta en cPanel
01 de ago de 2026
Cómo instalar SSL gratis con Let's Encrypt en un VPS sin cPanel (Nginx), paso a paso
Carolina
CTO - NAP Latino
www.naplatino.com
soporte@naplatino.com
