¿Cuánta RAM necesita una base de datos autoalojada?

Para una app — una instancia de Postgres o Redis más su backend — 1,7-2 GB es un conjunto de trabajo realista, así que Small (8 $) encaja. Varias apps, o una base de datos de producción con concurrencia real, te empujan a Medium (12 $), y si otras máquinas necesitan alcanzarla, a un plan con IP dedicada. Dimensiónala por conjunto de trabajo y número de conexiones, no por esperanza.

¿Por qué autoalojar en lugar de una base de datos gestionada?

Control. Obtienes todo el postgresql.conf, superusuario y cualquier extensión que quieras — pgvector, PostGIS, TimescaleDB, pg_cron — cosas que los niveles gestionados suelen bloquear o cobrar aparte. La contrapartida es que los backups, el ajuste y las actualizaciones corren de tu cuenta. Si quieres ser dueño de la máquina, ese es el punto.

¿Un VPS compartido sirve para una base de datos de producción?

Para una app de pequeña a moderada, sí. Para OLTP intenso — cientos de transacciones por segundo, escrituras críticas en latencia — una máquina de vCPU compartida es la herramienta equivocada, y lo diremos en lugar de venderte una. El I/O de disco y un reloj garantizado importan ahí, y los planes compartidos no prometen ninguno de los dos.

¿Cómo dejo que mis otros servidores se conecten a la base de datos?

Enlaza Postgres a la interfaz correcta, abre el puerto solo a las IP que lo necesiten, y usa un plan con una IPv4 dedicada para que la dirección sea estable y alcanzable. Nunca expongas el 5432 a todo internet — protégelo con cortafuegos hacia tus servidores de app y exige TLS.

¿Necesito darles un documento de identidad?

No. Un correo para registrarte, USDC o USDT para pagar. Sin documentos, root en aproximadamente un minuto.

VPS para una base de datos

Autoaloja PostgreSQL o Redis en un VPS con root completo — todo el postgresql.conf, extensiones que un servicio gestionado no te deja instalar, y límites honestos sobre lo que una máquina compartida puede y no puede aguantar. Desde 8 $/mes.

Hay un momento concreto en el que una base de datos gestionada deja de ser cómoda y empieza a ser un muro. Quieres una extensión que el nivel no ofrece. Quieres ver el plan de consulta real y ajustar work_mem. Quieres un superusuario. Un servicio gestionado es un gran valor por defecto hasta justo el momento en que necesitas ser dueño de la cosa — y entonces un VPS con root completo es la respuesta honesta.

Esta página trata de ejecutar tu propio PostgreSQL o Redis correctamente, y de ser claro sobre dónde una máquina compartida es la decisión adecuada y dónde no.

Qué necesita realmente una base de datos

A las bases de datos les importan dos cosas que a un servidor de juegos no: memoria para el conjunto de trabajo e I/O de disco. La forma aproximada:

Una app — una instancia de Postgres (o Redis) más un servicio backend. El conjunto de trabajo suele ser de 1,7-2 GB. Small (8 $) lo gestiona sin dramas.
Unas cuantas apps, o concurrencia de producción real — más conexiones, cachés más grandes, trabajos en segundo plano. Medium (12 $) te da el margen.
Otras máquinas necesitan alcanzarla — quieres una dirección estable y enrutable, así que un plan con IPv4 dedicada (Small-IP 16 $ en adelante). Más sobre esto abajo.

Redis es aún más ligero — está limitado por memoria, así que dimensiona el plan a tu conjunto de datos más overhead y listo. Postgres es el que recompensa un poco de ajuste.

La verdadera razón para autoalojar: control

Aquí es donde un VPS se gana su sitio. En tu propia máquina obtienes:

Todo el postgresql.conf — shared_buffers, work_mem, max_connections, ajustes de WAL, todo, afinado a tu carga de trabajo en lugar de a los valores por defecto de un proveedor.
Cualquier extensión. pgvector para embeddings y búsqueda semántica, PostGIS para geoespacial, TimescaleDB para series temporales, pg_cron, pg_stat_statements — instala lo que necesites. Los niveles gestionados frecuentemente restringen la lista de extensiones o la bloquean tras un plan superior.
Superusuario y el SO por debajo. Puedes mover el directorio de datos, ajustar el kernel, ejecutar pg_dump con tu propio calendario, y montar replicación por streaming a otra máquina si la quieres.

Si nada de eso te importa, una base de datos gestionada está genuinamente bien y deberías usar una. Esta página es para el caso en que sí importa.

Dónde una máquina compartida es la herramienta equivocada

Siendo directos: un VPS de vCPU compartida no está hecho para OLTP intenso — cientos de transacciones por segundo con escrituras críticas en latencia. Esa carga vive o muere por el I/O de disco garantizado y un reloj estable, y los planes compartidos no prometen ninguno. Si eres tú, quieres hardware dedicado, y preferimos decírtelo ahora que ver cómo tu latencia p99 nos avergüenza a ambos.

Para el caso mucho más común — una base de datos detrás de una app, una herramienta interna, un almacén de analítica, una caché — un plan compartido es exactamente lo adecuado.

Los backups no son opcionales

Autoalojar significa que los backups son tu trabajo, y la única regla es: hazlos antes de necesitarlos. Para Postgres, pg_dump en un cron para backups lógicos, o archivado de WAL para recuperación a un punto en el tiempo en cualquier cosa que de verdad te importe. Envía los volcados fuera de la máquina — a almacenamiento de objetos o a otro servidor — para que un disco muerto no se lleve los backups con él. Prueba una restauración al menos una vez. Un backup que nunca has restaurado es una esperanza, no un backup.

Dejar que otros servidores se conecten

Si la base de datos solo sirve a una app en la misma máquina, enlázala a localhost y listo — nada que exponer. En el momento en que otra máquina necesita entrar, dos cosas cambian:

Necesitas una dirección estable y enrutable — eso es un plan con IPv4 dedicada (Small-IP 16 $, Medium-IP 20 $). Los planes NAT comparten una dirección, lo cual está bien para salida pero no para ser una base de datos a la que otros servidores llaman.
La proteges con cortafuegos a fondo. Abre el 5432 (o el 6379) solo a las IP concretas que lo necesiten, nunca a 0.0.0.0/0, y exige TLS. Un puerto Postgres abierto en el internet público se encuentra en minutos.

Elegir el plan

Configuración	Plan
BD detrás de una app, solo localhost	Small (8 $)
Unas cuantas apps / concurrencia de producción	Medium (12 $)
Otros servidores deben conectarse	Small-IP (16 $) / Medium-IP (20 $)
OLTP intenso, cientos de TPS	hardware dedicado, no un VPS compartido

La mayoría de las bases de datos autoalojadas empiezan en Small y crecen a Medium o a un plan con IP dedicada a medida que asumen más apps o clientes externos.

Por qué aquí

Root completo significa que es tu base de datos, hasta el fondo — cada línea de configuración, cada extensión, tu propio calendario de backups, sin ningún nivel decidiendo qué te está permitido instalar. El pago es cripto (USDC o USDT en Base, Ethereum o Polygon), sin KYC, sin documentos. Root en unos 60 segundos tras el pago, y puedes tener Postgres aceptando conexiones unos minutos después.

El resumen honesto: autoaloja cuando quieras control — extensiones, ajuste, superusuario — y cuando tu carga de trabajo sea moderada. Para la base de datos de una app pequeña o mediana, un plan compartido es la herramienta adecuada. Para cientos de TPS de OLTP crítico en latencia, no lo es, y lo diremos. ¿Listo? Elige un plan.