Guía sobre el almacenamiento de datos de aplicaciones

Introducción: el viaje de los datos de tu aplicación

Has dedicado tiempo y esfuerzo a desarrollar una aplicación. Quizás es un gestor para tu colección de cartas Pokémon, una herramienta para organizar recetas o un blog personal. La lógica funciona, la interfaz es atractiva, pero entonces surge una pregunta fundamental que define la robustez y el futuro de tu proyecto: ¿dónde se guardan los datos? Cuando un usuario registra su colección de cartas, ¿a dónde va esa información? ¿Y las imágenes de cada carta? ¿Y los datos del propio usuario?

Esta cuestión, aparentemente simple, abre un abanico de posibilidades y decisiones arquitectónicas críticas. La respuesta no es única; depende enteramente de la estrategia de despliegue y la escala que preveas para tu aplicación. No existe una solución universal, sino un espectro de opciones, cada una con sus propias ventajas, desventajas y complejidades.

Análisis del caso de uso (App de cartas Pokémon)

Para ilustrar este viaje, tomemos como ejemplo una aplicación para gestionar colecciones de cartas Pokémon. Los datos que esta aplicación necesita manejar se pueden clasificar en dos grandes grupos:

• Datos estructurados: Son datos organizados que encajan perfectamente en tablas o documentos con un formato definido. En nuestro caso, serían:
  • Información del usuario: Nombre de usuario, correo electrónico, contraseña (cifrada), fecha de registro.
  • Inventario de cartas: Una lista que asocia a cada usuario con las cartas que posee, incluyendo detalles como la cantidad, el estado de la carta (nueva, usada), si es holográfica, etc.
  • Lista maestra de cartas: Un catálogo completo de todas las cartas Pokémon que han existido, con su nombre, número, expansión, tipo, ataques, etc. Este es un conjunto de datos de solo lectura que la aplicación utiliza como referencia.
• Datos no estructurados: Son datos que no tienen un modelo predefinido, como ficheros multimedia. En nuestra aplicación, el ejemplo más claro son:
  • Imágenes de cada carta: Ficheros (JPEG, PNG) que muestran el anverso y reverso de cada carta de la lista maestra. Estos ficheros deben almacenarse y servirse eficientemente. Aplicaciones como Collectr gestionan bases de datos con más de un millón de productos, lo que demuestra la escala que pueden alcanzar estos datos.

La elección de dónde y cómo almacenar estos dos tipos de datos es el núcleo del problema. ¿Guardamos todo en el ordenador del usuario? ¿Lo subimos a un servidor en la nube? ¿O montamos nuestro propio servidor en casa? Cada camino tiene implicaciones directas en la accesibilidad, la escalabilidad, el coste, la seguridad y el mantenimiento.

Hoja de ruta del artículo

Este artículo te guiará a través de los escenarios más comunes de despliegue de una aplicación, desde el entorno de desarrollo más básico hasta las arquitecturas en la nube más complejas. En cada sección, nos centraremos en responder con precisión a la pregunta: "¿dónde residen físicamente los datos?". Analizaremos las tecnologías implicadas, sus pros y sus contras, y determinaremos para qué tipo de proyecto es más adecuado cada enfoque. Al final, tendrás un mapa claro para tomar la decisión correcta para tu propia aplicación, ya sea un gestor de cartas Pokémon o el próximo gran proyecto tecnológico.

Escenario 1: el punto de partida, ejecución y datos en local

Todo proyecto de software nace en un entorno local. Es el campo de pruebas inicial, el lugar donde el código cobra vida por primera vez. En este escenario, la aplicación, su lógica y todos sus datos conviven en una única máquina: tu ordenador personal. Es el enfoque más directo y sencillo, ideal para las fases de prototipado y desarrollo.

¿Dónde se alojan los datos?

En un entorno puramente local, los datos se guardan directamente en el disco duro de tu ordenador. No hay servidores remotos ni conexiones a internet involucradas para el almacenamiento. Las dos formas más comunes de lograr esto son mediante bases de datos embebidas o ficheros planos.

Bases de datos embebidas (como SQLite)

• Ubicación: Los datos se almacenan en un único fichero, por ejemplo, coleccion_pokemon.db. Este fichero reside en una carpeta dentro de tu proyecto, junto al código fuente de la aplicación. Físicamente, es un archivo más en tu disco duro (C:, D:, etc.) o en tu carpeta de usuario.
• Funcionamiento: SQLite es una biblioteca que se integra directamente en tu aplicación. No es un programa servidor que se ejecuta en segundo plano como PostgreSQL o MySQL. Tu aplicación utiliza esta biblioteca para crear, leer y escribir en el fichero .db. Como describe DataCamp, SQLite funciona directamente dentro del software que lo utiliza, sin necesidad de un servidor central.
• Ideal para: Este modelo es perfecto para aplicaciones que no necesitan ser accedidas por múltiples usuarios simultáneamente. Es el estándar de facto para aplicaciones móviles (Android e iOS lo usan internamente), aplicaciones de escritorio y para prototipos rápidos donde la complejidad de un servidor de base de datos sería excesiva. Proyectos individuales o prototipos son su caso de uso principal.

Ficheros planos (JSON, CSV, etc.)

• Ubicación: Son simples ficheros de texto, como mi_coleccion.json o usuarios.csv, guardados en el disco duro local, usualmente dentro del directorio del proyecto.
• Funcionamiento: La aplicación abre estos ficheros, lee su contenido en memoria, lo modifica y luego lo vuelve a escribir en el disco. Es un proceso manual de serialización y deserialización de datos.
• Ideal para: Almacenar datos de configuración, pequeños conjuntos de datos que no cambian con frecuencia o para exportar/importar información. No es recomendable para datos que se modifican constantemente o que tienen relaciones complejas, ya que es ineficiente y propenso a errores.

Análisis y limitaciones

El enfoque local es el primer paso natural en el desarrollo de cualquier aplicación.

Para nuestra aplicación de cartas Pokémon, empezar con SQLite en local es una excelente opción. Permite construir toda la lógica de gestión de la colección y los usuarios de forma rápida. Sin embargo, en el momento en que queramos acceder a la colección desde otro dispositivo o compartirla con amigos, este modelo se quedará corto y tendremos que evolucionar hacia uno de los siguientes escenarios.

Escenario 2: contenerización con Docker, aislando la aplicación y persistiendo los datos

El siguiente paso evolutivo en el despliegue de aplicaciones es la contenerización, y Docker es el estándar de facto. Un contenedor es un paquete ligero y portable que incluye una aplicación y todas sus dependencias (librerías, configuraciones, etc.). Esto resuelve el problema de "funciona en mi máquina pero no en la tuya". Sin embargo, los contenedores introducen un nuevo desafío: son efímeros. Por diseño, cualquier cambio realizado dentro del sistema de ficheros de un contenedor se pierde cuando este se elimina. Para aplicaciones con estado, como nuestra app de Pokémon que necesita guardar datos, la persistencia es una necesidad absoluta.

¿Dónde se alojan los datos?

Aunque la aplicación se ejecuta dentro de un contenedor aislado, los datos persistentes no viven dentro de él. Los datos se guardan en el sistema de ficheros de la máquina anfitriona (tu PC, un servidor en la nube, etc.), pero se conectan al contenedor a través de mecanismos específicos de Docker. Esto desacopla el ciclo de vida de los datos del ciclo de vida del contenedor. Puedes actualizar, reiniciar o incluso reemplazar el contenedor de tu aplicación sin perder la información de los usuarios o las colecciones de cartas.

Mecanismos de persistencia en Docker

Docker ofrece principalmente dos mecanismos para lograr la persistencia de datos, cada uno con un propósito claro.

Volúmenes (método recomendado)

• Ubicación: Docker crea y gestiona una carpeta específica dentro de su propio directorio de almacenamiento en la máquina anfitriona. Por ejemplo, en Linux, esta ruta suele ser /var/lib/docker/volumes/nombre_del_volumen/_data. Lo importante es que Docker gestiona completamente esta ubicación, y no se supone que debas interactuar directamente con ella.
• Funcionamiento: Se crea un "volumen" con un nombre (ej: pokemon_db_data) y se "monta" en una ruta específica dentro del contenedor. Por ejemplo, si usamos una base de datos PostgreSQL en un contenedor, montaríamos nuestro volumen en /var/lib/postgresql/data, que es donde PostgreSQL guarda sus ficheros de datos.
• Ideal para: Es la práctica recomendada para almacenar datos de aplicaciones en producción, especialmente bases de datos (PostgreSQL, MariaDB, MongoDB). Los volúmenes son portables, su ciclo de vida es independiente del contenedor y pueden ser gestionados de forma segura por las herramientas de Docker.

Bind Mounts

• Ubicación: Una carpeta o fichero que tú eliges en tu máquina anfitriona (ej: C:\Users\TuUsuario\Proyectos\pokemon-app\datos o ~/projects/pokemon-app/data) se mapea directamente a una ruta dentro del contenedor.
• Funcionamiento: Es un enlace directo y transparente. Cualquier cambio que el contenedor haga en la ruta montada se refleja instantáneamente en la carpeta de la máquina anfitriona, y viceversa.
• Ideal para: Principalmente para entornos de desarrollo. Por ejemplo, puedes montar la carpeta de tu código fuente en el contenedor. Así, cada vez que modificas un fichero de código en tu editor, el cambio se refleja dentro del contenedor sin necesidad de reconstruir la imagen. Es perfecto para compartir código fuente o artefactos de compilación. Sin embargo, son menos portables (dependen de la estructura de directorios del anfitrión) y pueden causar problemas de permisos.

Ejemplo práctico con docker-compose.yml para la app de Pokémon

Docker Compose es una herramienta para definir y ejecutar aplicaciones Docker multi-contenedor. Con un simple fichero YAML, podemos orquestar nuestra aplicación y su base de datos, asegurando la persistencia de los datos.

Para nuestra app de Pokémon, podríamos tener un servicio api (la aplicación en sí) y un servicio db (la base de datos PostgreSQL). Así es como aseguraríamos que los datos de la colección y los usuarios persistan:

version: '3.8'

services:
  api:
    build: .
    ports:
      - "8000:8000"
    depends_on:
      - db
    environment:
      - DATABASE_URL=postgresql://user:password@db:5432/pokemon_db

  db:
    image: postgres:15
    environment:
      - POSTGRES_DB=pokemon_db
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password
    volumes:
      # Aquí está la magia: montamos el volumen 'pokemon_db_data'
      # en la carpeta donde PostgreSQL guarda sus datos.
      - pokemon_db_data:/var/lib/postgresql/data

# Aquí declaramos el volumen. Docker se encargará de crearlo y gestionarlo.
volumes:
  pokemon_db_data:
        

En este ejemplo, cuando ejecutas docker-compose up, Docker hace lo siguiente:

1. Crea una red para que los contenedores api y db se comuniquen.
2. Crea un volumen gestionado por Docker llamado pokemon_db_data.
3. Inicia el contenedor de PostgreSQL (db) y monta el volumen pokemon_db_data en su directorio de datos.
4. Inicia el contenedor de la aplicación (api), que se conecta a la base de datos.

Ahora, si detienes y eliminas los contenedores con docker-compose down, el volumen pokemon_db_data permanece intacto. La próxima vez que levantes la aplicación, el nuevo contenedor de PostgreSQL se conectará al mismo volumen y todos tus datos (usuarios, cartas, etc.) estarán ahí. Esta es la forma estándar de gestionar datos persistentes con Docker Compose.

Escenario 3: despliegue en la nube, servicios gestionados (Google Cloud)

Cuando una aplicación necesita ser accesible públicamente, escalable y altamente disponible, la nube es la respuesta más común. En lugar de gestionar servidores físicos, delegamos esa responsabilidad a un proveedor como Google Cloud, AWS o Azure. Utilizaremos servicios "serverless" o gestionados, como Google Cloud Run, que ejecutan nuestros contenedores sin que tengamos que preocuparnos por la infraestructura subyacente. Sin embargo, estos servicios son inherentemente stateless (sin estado), lo que significa que no guardan datos entre ejecuciones. Por lo tanto, es obligatorio conectarlos a servicios de almacenamiento persistente externos.

¿Dónde se alojan los datos?

En este modelo, los datos no residen en el mismo lugar donde se ejecuta el código de tu aplicación. Los datos viven en la infraestructura global, redundante y altamente escalable del proveedor de la nube. Físicamente, están distribuidos en discos duros y sistemas de almacenamiento en múltiples centros de datos gestionados por Google. Tú, como desarrollador, no tienes acceso directo a estos discos físicos. En su lugar, interactúas con tus datos a través de APIs seguras y conexiones de red, mientras el proveedor se encarga de la durabilidad, las copias de seguridad y la replicación.

Opciones de almacenamiento en Google Cloud para la app de Pokémon

Para nuestra aplicación de cartas Pokémon desplegada en Cloud Run, necesitaríamos combinar diferentes servicios de almacenamiento de Google Cloud, cada uno especializado en un tipo de dato.

La elección correcta depende de la naturaleza de los datos y los patrones de acceso.

Datos estructurados (usuarios, colección)

Para la información de los usuarios y el inventario de cartas, que son datos relacionales o semi-estructurados, tenemos dos excelentes opciones:

• Cloud SQL (Base de datos relacional):
  • Ubicación: Los datos se almacenan en Google Persistent Disks, que son dispositivos de almacenamiento en bloque duraderos y de alto rendimiento. Google gestiona la redundancia y las copias de seguridad automáticas. Tú eliges el tipo de base de datos (PostgreSQL, MySQL o SQL Server) y la región, pero no gestionas el sistema operativo ni el hardware.
  • Ideal para: Datos con un esquema estricto y relaciones complejas. Si tu aplicación requiere transacciones ACID (atomicidad, consistencia, aislamiento, durabilidad) y la potencia de SQL, Cloud SQL es la opción tradicional. Sin embargo, puede tener un coste base más elevado, ya que pagas por la instancia mientras esté encendida, incluso si no recibe tráfico, lo que ha generado debates sobre su coste en foros como Reddit.
• Firestore (Base de datos NoSQL):
  • Ubicación: Los datos se guardan como documentos (similares a JSON) dentro de colecciones, en una base de datos distribuida y replicada automáticamente en múltiples regiones de Google. Firestore está diseñado para escalar globalmente y ofrece una alta disponibilidad por defecto.
  • Ideal para: Datos con esquemas flexibles que pueden cambiar con el tiempo. Es perfecto para aplicaciones que necesitan sincronización de datos en tiempo real (los cambios se propagan a todos los clientes conectados instantáneamente) y soporte sin conexión para aplicaciones móviles y web. Su modelo de precios se basa en el número de lecturas, escrituras y la cantidad de datos almacenados, lo que puede ser extremadamente económico para aplicaciones con poco tráfico, ya que no hay un coste fijo por tener la base de datos "encendida".

Datos no estructurados (imágenes de las cartas)

Para los ficheros de imagen, la solución estándar en la nube es el almacenamiento de objetos.

• Cloud Storage (Almacenamiento de objetos):
  • Ubicación: Los ficheros (imágenes, vídeos, documentos) se guardan como "objetos" dentro de contenedores llamados "buckets". Estos buckets no están atados a un disco específico, sino que se distribuyen en la vasta infraestructura de almacenamiento de Google para garantizar una durabilidad y disponibilidad masivas.
  • Funcionamiento: La aplicación (ejecutándose en Cloud Run) subiría la imagen de una carta a un bucket de Cloud Storage. Luego, guardaría la URL pública de esa imagen o su identificador único en el registro correspondiente de la base de datos (Firestore o Cloud SQL). Cuando un usuario quiera ver la carta, la aplicación recupera la URL de la base de datos y el navegador del cliente descarga la imagen directamente desde Cloud Storage, liberando a tu aplicación de esa carga.
  • Ideal para: Almacenar y servir grandes cantidades de ficheros estáticos. Es una solución increíblemente económica, duradera y escalable.

Tabla resumen para el enfoque en la nube

La siguiente tabla resume la estrategia recomendada para nuestra aplicación de Pokémon en Google Cloud:

En resumen, un despliegue moderno en la nube para nuestra aplicación implicaría una arquitectura de microservicios donde la lógica de la aplicación (Cloud Run) está completamente separada de sus datos, utilizando el servicio de almacenamiento más adecuado para cada tipo de información.

Escenario 4: la ruta del autoalojamiento (Self-Hosting), control total

El autoalojamiento es la filosofía de operar tus propios servidores en lugar de depender de servicios de terceros como Google Cloud. Este enfoque te otorga el máximo control sobre tu software y tus datos, una soberanía digital completa. Te permite crear tu propia nube para documentos, fotos y servicios. Aunque puede ser más económico a largo plazo, conlleva una mayor responsabilidad técnica en términos de configuración, mantenimiento y seguridad.

¿Dónde se alojan los datos?

En el mundo del autoalojamiento, los datos residen en hardware que tú controlas, ya sea alquilado en un centro de datos o físico en tu propia casa.

Opción A: Servidor Privado Virtual (VPS)

• Ubicación: Los datos se guardan en el disco duro (generalmente SSD o NVMe) de una máquina virtual que alquilas a un proveedor de hosting como Contabo, Hetzner u OVHcloud. Físicamente, estos discos están en los centros de datos del proveedor, pero tú tienes acceso completo a nivel de sistema operativo.
• Funcionamiento: Un VPS es como tener un ordenador con Linux conectado a internet 24/7. Tienes acceso root (administrador) y puedes instalar lo que necesites. Para nuestra app de Pokémon, el flujo de trabajo sería:
  1. Contratar un VPS con suficiente RAM y almacenamiento.
  2. Instalar Docker y Docker Compose.
  3. Desplegar la aplicación usando el mismo fichero docker-compose.yml del Escenario 2.
  En este caso, los volúmenes de Docker que contienen los datos de la base de datos y las imágenes residirán en el disco duro virtual del VPS. Tú eres el responsable de configurar el servidor, asegurar el sistema operativo, aplicar parches de seguridad y, crucialmente, implementar una estrategia de copias de seguridad.

Opción B: Servidor Casero (DIY)

• Ubicación: En los discos duros físicos que tú posees y que están en tu casa. Estos discos están conectados a un ordenador dedicado que actúa como servidor. Este puede ser un PC antiguo, un miniordenador de bajo consumo como una Raspberry Pi con Nextcloud, o un dispositivo NAS (Network Attached Storage) comercial.
• Funcionamiento: Es la máxima expresión del control. Instalas un sistema operativo orientado a servidores (como Debian, Ubuntu Server, o una solución NAS como OpenMediaVault). Sobre este sistema, instalas el software necesario, como Docker, para ejecutar tu aplicación. Eres responsable de absolutamente todo: la compra y mantenimiento del hardware, el coste de la electricidad, la configuración de tu red doméstica para que el servidor sea accesible desde internet (si lo deseas) y la seguridad física del dispositivo.

Análisis y consideraciones

La ruta del autoalojamiento es poderosa pero exigente. Ofrece una alternativa atractiva al modelo de "pago por uso" de la nube, especialmente para proyectos personales o para quienes valoran la privacidad y el control por encima de todo.

Para la aplicación de Pokémon, un VPS económico es un punto intermedio excelente. Te da una IP pública y un servidor siempre encendido por un coste predecible, y puedes usar Docker para gestionar la aplicación de la misma forma que lo harías en local, pero haciéndola accesible a todo el mundo.

Escenario 5: orquestación avanzada con Kubernetes, escalabilidad a gran escala

Kubernetes (a menudo abreviado como K8s) es el sistema de orquestación de contenedores de código abierto que se ha convertido en el estándar de la industria para desplegar, escalar y gestionar aplicaciones complejas y distribuidas. Mientras que Docker te permite ejecutar un contenedor en una sola máquina, Kubernetes te permite ejecutar y gestionar miles de contenedores en un clúster de muchas máquinas, ya sean virtuales o físicas. Para un proyecto simple como una app personal de cartas Pokémon, Kubernetes es una solución excesiva (overkill), pero es fundamental entender su modelo de almacenamiento para comprender cómo funcionan las aplicaciones a gran escala.

¿Dónde se alojan los datos?

La filosofía central de Kubernetes es la abstracción. Al igual que abstrae los servidores físicos en un "pool" de recursos de cómputo, también abstrae el almacenamiento. El concepto clave es la disociación total entre el ciclo de vida de la aplicación (llamada Pod en Kubernetes) y el ciclo de vida del almacenamiento. Un Pod puede ser destruido, reiniciado en otra máquina del clúster o escalado a múltiples réplicas, pero los datos deben persistir de forma independiente.

Entonces, ¿dónde están los datos? La respuesta es: el dato reside en el medio de almacenamiento físico o virtual que respalda al PersistentVolume. La capa de Kubernetes (PV, PVC) actúa como un intermediario, una API que permite a las aplicaciones solicitar y consumir almacenamiento de forma estandarizada, sin necesidad de conocer los detalles de la implementación subyacente.

• En un clúster en la nube (como Google Kubernetes Engine – GKE), un PersistentVolume suele ser un recurso de almacenamiento en la nube, como un Google Persistent Disk, un Amazon EBS Volume o un Azure Disk. Los datos están físicamente en los centros de datos del proveedor de la nube.
• En un clúster autoalojado (on-premise), un PersistentVolume podría ser un directorio en un servidor local (hostPath), un recurso de red compartido a través de NFS, o un volumen de una red de área de almacenamiento (SAN) como iSCSI. Los datos están físicamente en tu propio hardware.

Mecanismos de persistencia en Kubernetes

Kubernetes introduce varios objetos API para gestionar el almacenamiento con estado:

1. PersistentVolume (PV): Es un recurso en el clúster que representa una "pieza" de almacenamiento. Un administrador del clúster lo provisiona estáticamente o se crea dinámicamente. El PV contiene los detalles de la implementación real del almacenamiento (tipo, tamaño, ruta, etc.), pero abstrae estos detalles de la aplicación.
2. PersistentVolumeClaim (PVC): Es una "solicitud" de almacenamiento realizada por una aplicación (o un usuario). Es similar a cómo un Pod solicita recursos de CPU y memoria. En el fichero de configuración de la aplicación, se define un PVC especificando, por ejemplo, "necesito 20GB de almacenamiento con acceso de lectura/escritura". Kubernetes se encarga de encontrar un PV disponible que satisfaga esa solicitud y los "enlaza" (bind). El PVC actúa como un conector entre el Pod y el PV.
3. StorageClass: Permite la provisión dinámica de almacenamiento. En lugar de que un administrador cree manualmente los PVs, se define una "clase" de almacenamiento (ej: "fast-ssd", "cheap-hdd"). Cuando una aplicación solicita almacenamiento a través de un PVC que especifica una StorageClass, Kubernetes instruye automáticamente al proveedor de almacenamiento subyacente (ej: Google Cloud) para que cree un nuevo PV que cumpla con las especificaciones.
4. StatefulSet: Este es un tipo de controlador de Kubernetes, similar a un Deployment, pero diseñado específicamente para aplicaciones con estado como bases de datos. Un StatefulSet proporciona garantías sobre el orden y la unicidad de sus Pods. A cada Pod se le asigna una identidad de red estable y un almacenamiento persistente único que se mantiene incluso si el Pod se reinicia o se reprograma en otro nodo. Para nuestra app de Pokémon, si la base de datos se ejecutara en Kubernetes, se gestionaría con un StatefulSet para asegurar que cada réplica de la base de datos se conecte siempre a su volumen de datos correcto.

En esencia, el flujo es el siguiente: una aplicación definida en un StatefulSet crea un PersistentVolumeClaim solicitando almacenamiento. Kubernetes, a través de una StorageClass, provisiona dinámicamente un PersistentVolume (por ejemplo, un disco en la nube) y lo enlaza al PVC. Finalmente, el Pod de la aplicación monta este PVC como un volumen local, pudiendo leer y escribir datos que persistirán más allá de su propia existencia.

Conclusión: eligiendo el hogar adecuado para los datos de tu aplicación

Hemos viajado desde el disco duro de tu ordenador personal hasta los clústeres distribuidos de Kubernetes, explorando los diversos lugares donde los datos de tu aplicación pueden residir. La elección correcta no es una cuestión de "mejor" o "peor" en abstracto, sino de encontrar el equilibrio adecuado entre simplicidad, coste, escalabilidad, control y esfuerzo de mantenimiento para las necesidades específicas de tu proyecto.

Resumen de las opciones

La siguiente tabla consolida todos los escenarios, proporcionando una vista panorámica para ayudarte a tomar una decisión informada. El foco principal sigue siendo la ubicación de los datos y los factores clave que influyen en cada elección.

Recomendaciones finales para la app de Pokémon

Volviendo a nuestro caso de uso, aquí tienes una hoja de ruta pragmática:

1. Para empezar a desarrollar y aprender: Comienza con Docker en tu ordenador local. Usa docker-compose para gestionar un contenedor para tu aplicación y otro para una base de datos PostgreSQL, con los datos persistiendo en un volumen de Docker. Este enfoque es el estándar de la industria, te enseña habilidades valiosas y te prepara para cualquier despliegue futuro.
2. Para lanzar una aplicación pública y escalable: La combinación de Cloud Run (para la aplicación), Firestore (para los datos de usuarios y colección) y Cloud Storage (para las imágenes de las cartas) es una opción moderna, extremadamente potente y con un coste inicial muy bajo gracias a sus generosos planes gratuitos. Te liberas de la gestión de servidores y pagas solo por lo que usas, permitiendo que tu aplicación crezca sin fricción.
3. Para un entusiasta con presupuesto limitado que quiere control: Alquilar un VPS económico (por ejemplo, de Contabo o Hetzner por 5-10€/mes) e instalar Docker es el punto dulce perfecto. Te ofrece un servidor siempre activo con una IP pública y un coste fijo, dándote un control casi total sobre el entorno sin tener que preocuparte por el hardware físico. Es una solución robusta y flexible para proyectos personales serios.

Al final del día, el "hogar" de tus datos es una de las decisiones más importantes que tomarás. Comprender dónde viven, cómo se protegen y cómo crecen junto a tu aplicación es la clave para construir software duradero y fiable.