A worker in Transit targets a 30-second start-to-start cadence as it asks the STM feeds for the latest trip and vehicle data. When Postgres ran on Neon and the worker ran on Railway, those two managed services cost me about $50 to $60 per month.
I moved the database and worker to an existing Oracle A1 Flex VM. As of July 2026, that VM costs me $0 under the A1 allowance attached to my PAYG account. The rest of Transit still uses infrastructure outside the VM, and Oracle's limits for new accounts may differ. This is a case study of my setup, not a recipe.
My VM is in Montréal. It has 4 OCPUs, about 24 GB of RAM, and a 200 GB-class disk. Five services run there: Postgres with PostGIS, the realtime worker, a separate database pruner, a health API, and Caddy. The database and worker moved off Neon and Railway; the external parts of Transit did not move onto this box.
Low recurring cost matters because Transit is a long-lived public portfolio and civic-data project. A smaller bill makes it easier for me to keep operating it, but I did not remove cost from the system. I exchanged managed-service spend for a tighter machine boundary and more work of my own.
At a historical peak, one realtime table held roughly half a billion rows and the Postgres volume reached about 139 GB. Those numbers are old scale receipts, not today's database size. On a 200 GB-class disk, keeping detail indefinitely was not an option.
The raw archive already existed. The cap forced me to make the retention budget explicit. As verified in July 2026, the live relational Silver layer keeps one day. Raw realtime GTFS-RT snapshots stay off-box in R2 for 90 days. Detailed Gold facts keep 14 days, while smaller rollups keep 730 days.
A separate database pruner handles Silver and Gold cleanup outside the capture loop. It does not prune the R2 archive. For a selected archived window, I have tested rebuilding realtime Silver and its derived Gold delay facts. That proves one recovery path, not a universal rebuild.
Static and historic snapshots use content hashes to skip unchanged files, while the live tier publishes every cycle. Together, the storage roles are explicit: live relational data stays query-ready, raw realtime data stays replayable off-box, and smaller rollups keep the long view.
Leaving managed services transferred responsibility to me. I own the backups, restore testing, monitoring, patching, capacity decisions, and incident response. The off-box logical backup intentionally excludes the largest replayable realtime Silver table, so recovery combines the backup with raw realtime replay. I have also run a restore drill against a separate database environment instead of treating the existence of a backup file as proof.
This is still one VM. If its host fails, the database and always-on pipeline are down while I restore or move the workload. The off-box site and existing snapshots can remain available, but their live data stops refreshing. There is no automatic failover.
The backup and replay paths reduce data-loss risk without creating high availability. That is the actual trade: lower vendor spend transferred more operational ownership to me.
Oracle controls the allowance and can change its terms. Anyone making a similar decision needs to check the current documentation instead of copying my July 2026 configuration.
I reduced the switching cost; I did not eliminate it. The VM services are containerized, database access is configuration-driven, and the raw realtime data and logical backups live off the VM. I have not yet tested a full provider migration. If Oracle changes the deal, moving will still take work, but the recovery inputs are not trapped on the host.
The same question shaped my website: what must stay live, and what can move out of the request path? Its content lives in a CMS that the live site never calls.
This is chapter 5 of a six-chapter epic. Chapters 1–3: who I am. Chapters 4–6: what I build. Previous: AI-accelerated, human-owned: my actual workflow · Next: Does your website need instant publishing?.
Need a system that stays editable?