De 50 $ à 0 $ : une VM Oracle Always Free

Un worker de Transit vise une cadence de 30 secondes d’un démarrage à l’autre lorsqu’il interroge les flux de la STM pour obtenir les plus récentes données sur les trajets et les véhicules. Lorsque Postgres fonctionnait sur Neon et le worker sur Railway, ces deux services gérés me coûtaient environ 50 à 60 $ par mois.

J’ai déplacé la base de données et le worker vers une VM Oracle A1 Flex existante. En juillet 2026, cette VM me coûte 0 $ dans le cadre du quota A1 associé à mon compte PAYG. Le reste de Transit utilise encore de l’infrastructure à l’extérieur de la VM, et les limites d’Oracle peuvent différer pour les nouveaux comptes. Il s’agit d’une étude de cas sur ma configuration, pas d’une marche à suivre.

Ma VM se trouve à Montréal. Elle compte 4 OCPU, environ 24 Go de mémoire vive et un disque d’une capacité nominale d’environ 200 Go. Cinq services y fonctionnent : Postgres avec PostGIS, le worker en temps réel, un service distinct qui purge la base de données, une API d’état de santé et Caddy. La base de données et le worker ont quitté Neon et Railway; les parties externes de Transit n’ont pas été déplacées sur cette machine.

Un faible coût récurrent compte parce que Transit est un projet public de données civiques qui fait partie de mon portfolio et qui est conçu pour durer. Une facture plus petite me permet de continuer à l’exploiter plus facilement, mais je n’ai pas supprimé les coûts du système. J’ai troqué les dépenses en services gérés contre les contraintes d’une seule machine et davantage de travail de ma part.

À un pic historique, une table en temps réel contenait environ un demi-milliard de lignes et le volume Postgres atteignait environ 139 Go. Ces chiffres témoignent d’une échelle passée; ils ne représentent pas la taille actuelle de la base de données. Sur un disque d’environ 200 Go, conserver les données détaillées indéfiniment n’était pas une option.

L’archive brute existait déjà. La limite m’a forcé à rendre le budget de rétention explicite. La vérification de juillet 2026 confirmait que la couche relationnelle Silver active conserve une journée. Les instantanés GTFS-RT bruts en temps réel restent hors de la VM dans R2 pendant 90 jours. Les faits Gold détaillés sont conservés pendant 14 jours, tandis que les agrégats plus petits le sont pendant 730 jours.

Un service distinct purge les couches Silver et Gold en dehors de la boucle de capture. Il ne purge pas l’archive R2. Pour une période choisie dans les archives, j’ai testé la reconstruction de la couche Silver en temps réel et des faits Gold dérivés sur les retards. Cela démontre un chemin de reprise, pas une reconstruction universelle.

Les instantanés statiques et historiques utilisent des hachages de contenu pour ignorer les fichiers inchangés, tandis que la couche active publie à chaque cycle. Ensemble, les rôles de stockage sont explicites : les données relationnelles actives restent prêtes à être interrogées, les données brutes en temps réel restent rejouables hors de la VM et les agrégats plus petits conservent la vue à long terme.

En quittant les services gérés, j’ai repris à ma charge les responsabilités qu’ils assumaient. Je suis responsable des sauvegardes, des tests de restauration, de la surveillance, des correctifs, des décisions de capacité et des interventions en cas d’incident. La sauvegarde logique hors de la VM exclut intentionnellement la plus grande table Silver en temps réel, qui peut être rejouée. La reprise combine donc la sauvegarde avec le rejeu des données brutes en temps réel. J’ai aussi exécuté un exercice de restauration dans un environnement de base de données distinct, plutôt que de considérer l’existence d’un fichier de sauvegarde comme une preuve.

Cela reste une seule VM. Si son hôte tombe en panne, la base de données et le pipeline toujours actif sont hors service pendant que je restaure ou déplace la charge de travail. Le site hors de la VM et les instantanés existants peuvent rester accessibles, mais leurs données en direct cessent de s’actualiser. Il n’y a aucun basculement automatique.

Les chemins de sauvegarde et de rejeu réduisent le risque de perte de données sans créer de haute disponibilité. Voilà le véritable compromis : la baisse des dépenses auprès des fournisseurs m’a transféré davantage de responsabilité opérationnelle.

Oracle contrôle le quota et peut en modifier les conditions. Quiconque envisage une décision semblable doit consulter la documentation actuelle au lieu de copier ma configuration de juillet 2026.

J’ai réduit le coût de changement de fournisseur; je ne l’ai pas éliminé. Les services de la VM sont conteneurisés, l’accès à la base de données est piloté par la configuration, et les données brutes en temps réel ainsi que les sauvegardes logiques se trouvent hors de la VM. Je n’ai pas encore testé une migration complète vers un autre fournisseur. Si Oracle change l’entente, le déplacement demandera encore du travail, mais les éléments nécessaires à la reprise ne sont pas prisonniers de l’hôte.

La même question a façonné mon site web : qu’est-ce qui doit rester en direct, et qu’est-ce qui peut être retiré du chemin de requête? Son contenu vit dans un CMS que le site en production n’appelle jamais.

Voici le chapitre 5 d’une épopée en six chapitres. Chapitres 1 à 3 : qui je suis. Chapitres 4 à 6 : ce que je construis. Précédent : Accéléré par l’IA, piloté par l’humain : mon vrai flux de travail · Suivant : Votre site web a-t-il besoin d’une publication instantanée?.