Un worker de Transit busca mantener una cadencia de 30 segundos entre el inicio de un ciclo y el siguiente mientras consulta los feeds de la STM para obtener los datos más recientes de viajes y vehículos. Cuando Postgres corría en Neon y el worker en Railway, esos dos servicios administrados me costaban entre 50 $ y 60 $ al mes.
Trasladé la base de datos y el worker a una VM Oracle A1 Flex que ya tenía. En julio de 2026, esa VM me cuesta 0 $ gracias a la asignación A1 asociada a mi cuenta PAYG. El resto de Transit todavía usa infraestructura fuera de la VM, y los límites de Oracle para cuentas nuevas pueden ser distintos. Este es un estudio de caso de mi configuración, no una receta.
Mi VM está en Montreal. Tiene 4 OCPU, unos 24 GB de RAM y un disco de alrededor de 200 GB. Allí corren cinco servicios: Postgres con PostGIS, el worker en tiempo real, un proceso separado de limpieza de la base de datos, una API de salud y Caddy. La base de datos y el worker salieron de Neon y Railway; las partes externas de Transit no se trasladaron a esta máquina.
El bajo costo recurrente importa porque Transit es un proyecto público de datos cívicos que forma parte de mi portafolio y está pensado para durar. Una factura menor me facilita mantenerlo en operación, pero no eliminé los costos del sistema. Cambié el gasto en servicios administrados por una infraestructura limitada a una sola máquina y más trabajo a mi cargo.
En un pico histórico, una tabla en tiempo real contenía cerca de quinientos millones de filas y el volumen de Postgres llegó a unos 139 GB. Esas cifras documentan una escala pasada, no el tamaño actual de la base de datos. En un disco de unos 200 GB, conservar el detalle indefinidamente no era una opción.
El archivo de datos brutos ya existía. El límite me obligó a hacer explícito el presupuesto de retención. Según la verificación de julio de 2026, la capa relacional Silver en producción conserva un día. Los snapshots brutos de GTFS-RT en tiempo real permanecen fuera de la VM, en R2, durante 90 días. Los hechos Gold detallados se conservan durante 14 días, mientras que los agregados más pequeños se guardan durante 730 días.
Un proceso separado de limpieza de la base de datos se encarga de depurar Silver y Gold fuera del ciclo de captura. No elimina datos del archivo R2. Para un periodo seleccionado dentro del archivo, probé la reconstrucción de Silver en tiempo real y de los hechos Gold derivados de retrasos. Eso demuestra una ruta de recuperación, no una reconstrucción universal.
Los snapshots estáticos e históricos usan hashes de contenido para omitir los archivos sin cambios, mientras que la capa en vivo publica en cada ciclo. En conjunto, las funciones de almacenamiento quedan claras: los datos relacionales en vivo siguen listos para consultas, los datos brutos en tiempo real se pueden reprocesar fuera de la VM y los agregados más pequeños conservan la visión a largo plazo.
Al dejar los servicios administrados, esas responsabilidades pasaron a mis manos. Quedaron a mi cargo las copias de seguridad, las pruebas de restauración, el monitoreo, la aplicación de parches, las decisiones de capacidad y la respuesta a incidentes. La copia de seguridad lógica fuera de la VM excluye intencionalmente la tabla Silver en tiempo real más grande, que se puede reconstruir mediante reprocesamiento; por eso, la recuperación combina la copia de seguridad con el reprocesamiento de los datos brutos en tiempo real. También hice un simulacro de restauración en un entorno de base de datos separado, en vez de tratar la existencia de un archivo de copia de seguridad como prueba suficiente.
Sigue siendo una sola VM. Si falla el host, la base de datos y el pipeline que corre continuamente quedan fuera de servicio mientras restauro o traslado la carga de trabajo. El sitio alojado fuera de la VM y los snapshots existentes pueden seguir disponibles, pero sus datos en vivo dejan de actualizarse. No hay failover automático.
Los mecanismos de copia de seguridad y reprocesamiento reducen el riesgo de pérdida de datos sin crear alta disponibilidad. Esa es la contrapartida real: un menor gasto en proveedores dejó más responsabilidad operativa en mis manos.
Oracle controla la asignación y puede cambiar sus condiciones. Cualquiera que tome una decisión similar debe consultar la documentación vigente en lugar de copiar mi configuración de julio de 2026.
Reduje el costo de cambiar de proveedor; no lo eliminé. Los servicios de la VM corren en contenedores, el acceso a la base de datos se define por configuración y los datos brutos en tiempo real, junto con las copias de seguridad lógicas, están fuera de la VM. Todavía no he probado una migración completa a otro proveedor. Si Oracle cambia las condiciones, trasladar el sistema seguirá requiriendo trabajo, pero los insumos de recuperación no están atrapados en el host.
La misma pregunta dio forma a mi sitio web: ¿qué debe seguir en vivo y qué puede quedar fuera de la ruta de cada solicitud? Su contenido vive en un CMS al que el sitio en producción nunca llama.
Este es el capítulo 5 de una saga de seis capítulos. Capítulos 1 a 3: quién soy. Capítulos 4 a 6: lo que construyo. Anterior: Acelerado por IA, en manos humanas: mi flujo de trabajo real · Siguiente: ¿Tu sitio web necesita publicación instantánea?.
¿Necesitas un sistema que se mantenga editable?