Complemento de base de datos o servidor de base de datos: la diferencia que de verdad importa
Por defecto, la base de datos de una app nueva corre como un complemento en el propio servidor de la app — barato, rápido, y exactamente lo correcto para empezar. Lo que vale la pena entender antes de que importe en producción: si se pierde ese servidor, los datos del complemento solo tienen tus backups como respaldo. Un servidor de base de datos es la otra opción — uno de tus propios servidores que guarda datos y nada más, con una historia de fallas significativamente distinta.
Qué cambia en realidad un servidor de base de datos
Mover los datos a un servidor de base de datos no es solo una máquina más grande. Cambia qué protege a los datos:
- No recibe ningún proxy web ni herramientas de build, y nunca se despliega ninguna app en él — existe para exactamente un trabajo.
- Los puertos de sus datastores solo están abiertos a los servidores de apps que lo usan, no son alcanzables en general.
- Backups, verificados. Cada base de datos de app en un servidor de base de datos recibe un backup diario, y cada uno se verifica restaurándolo de verdad — no se asume bueno solo porque el job reportó éxito.
- Un standby, en Pro y Team. Also create a standby aprovisiona un segundo servidor de base de datos del mismo tamaño que mantiene una copia en vivo de Postgres, MySQL y Redis, verificada cada 5 minutos.
- Failover automático. Si el primario deja de responder durante 3 minutos y el standby también perdió contacto de forma independiente, el standby toma el control en los puertos habituales, cada app que lo usa redespliega contra él, y recibes una notificación con el listado exacto de qué se movió.
Un complemento en el servidor de la app no tiene nada de esto por construcción — nunca fue pensado como la capa de durabilidad, solo como el valor por defecto conveniente.
Mover una app existente
Settings → Resources → Move data to a database server en la app, que lista exactamente qué se va a copiar y qué arranca vacío antes de que presiones el botón:
- La app se detiene.
- Postgres y MySQL se dumpean y se restauran en el servidor de base de datos.
- Redis, MongoDB, almacenamiento de objetos, definiciones de RabbitMQ y ClickHouse también se copian — un Elasticsearch usado solo por esta app también se traslada.
- La app redespliega.
Si algún paso falla, la app vuelve a sus datos viejos — de solo lectura, nunca sobrescritos — así que un traslado fallido no arriesga justo lo que estaba intentando proteger.
Cuándo el valor por defecto sigue siendo la decisión correcta
No toda app necesita esto desde el primer día. Una herramienta interna de bajo riesgo, un entorno de staging, cualquier cosa donde perder un día de datos y restaurar un backup sea un “ni modo” en vez de un incidente — el complemento por defecto está correctamente dimensionado para eso, y moverlo está a una pantalla de configuración de distancia siempre que el cálculo cambie. El punto no es “usa siempre un servidor de base de datos”. Es saber cuál de los dos estás corriendo en realidad antes de que una caída sea el momento en que te enteras.
Referencia completa, incluyendo connection pooling y upgrades de Postgres: Servidores de base de datos.