Field Report: Rails World 2025

Double Agents Mike Bowman, Pier-Luc Faucher, and Lee Quarella attended Rails World 2025 in Amsterdam.

Mike Bowman documented a field report with notes from the field on favorite talks, the venue, and the experience—including the amusing Ruby Embassy.

Rails World 2025: Notes from my favorite talks

Opening Keynote: DHH

This was an exciting keynote. There are some really cool features coming in Rails 8.1. I was especially excited about the concept of local CI, to encourage teams to run their test suites locally and provide a mechanism to eventually replace (or drastically reduce) the reliance on cloud CI runners, which can often become slow, bloated, and complex. I was also interested to hear about the 37Signals team’s transition away from using Apple products and into using Omarchy (https://omarchy.org/), a setup based on Arch Linux that DHH has been building.

One major focus of the talk was on what he refers to as the “Merchants of Complexity.” We (as an industry) have largely been convinced that certain things are too hard, too complex, too risky, to handle on our own. Hosting, databases, deployments, etc. His position is that we can cut away most of that complexity by taking better advantage of improvements in hardware and tooling. The local CI piece is a good example of this. Rather than relying on complex and expensive Github Actions, most engineers now have machines that are more than powerful enough to run their entire test suites locally, so why not cut out the middleman and just do that.

One of the features that he touched on was adding tentanting and SQLite replication to Rails apps, which are features that the so-called “merchants of complexity” can provide for us. Rails, however, is building these features themselves. It seemed a bit contradictory to me to spend so much time in the keynote urging people to simplify their setups, while then turning around and showing off their own custom-built replacements. I think the angle is maybe more along the lines of “we don’t need to pay other people to handle this complexity for us”, rather than “we don’t need this complexity at all”.

SQLite Replication With Beamer: Kevin McConnell (37Signals)

This was a deep technical discussion of how SQLite is architected, and how to hook into the features it provides to build a reliable replication system for it. I didn’t know much about the internals of the software, so it was super interesting to get a closer look. At the end of the day, it seems like this replication is simpler than I would have thought, although I’m sure there are edge cases that he didn’t discuss.

This tooling is called Beamer, and will be open-sourced at some point in the future. It will only work for SQLite at the moment, but he suggested that they’d be open to community support to get it up and running for Postgresql or MySQL as well.

Safely Managing Database Changes at Scale: Miles McGuire (Intercom)

This was an interesting technical talk about how to manage databases measuring in the hundreds of terabytes range. Intercom has multiple tables with tens of billions of rows.

He talked a bit about the iterations they’ve gone through to try to make some of these operations safer. First, they used checklists. Checklists are great, but they aren’t perfect. They need to be kept up to date as the processes change, and they rely on people to actually read and follow them.

Automated testing is much more reliable. At Intercom, they use a handful of custom Rubocop rules to prevent certain database operations in migration files.

What I found most interesting is that, as part of their production deployment pipeline, they added some code to the ActiveRecord Migrator to check the size of a table in production, and block operations on that table if it met certain criteria. Since it’s hard to replicate huge tables in development, they figured that the most reliable source was the production database itself. So, when a migration runs in production, it first examines the table in question and basically checks how many records it has, and how much space it takes up on disk. If either of those values are greater than a certain threshold, the migration is failed, the deployment cancelled, and their database team automatically receives a message saying that this migration will need to be managed manually by the database team.

I didn’t get a chance to talk to Miles after his talk, but I was curious about how this process interacted with the rest of their deployment pipeline, and how engineers need to handle situations where their deployments get blocked.

He shared some of their custom Rubocop rules and the Migrator monkey-patch at the following url: https://minuteman3.github.io/railsworld2025/

Lessons from Migrating a Legacy App to Turbo: Radan Skoric (Halalbooking)

Hotwire and its related tools are extremely flexible, it makes sense to lean into them and find ways to fit your work into their paradigms, since it ends up simplifying things

Optimize for the source of complexity. He gave an example of an app that had to render a complex search page, but the actual complexity was in the back end, so focus your efforts taming that, rather than building a complex front end which ends up being far away from the source.

Thoughts about the Rails World Venue & Experience

Hosted at the Beurs van Berlage, a historic building in central Amsterdam. Completed in 1903, it used to house the Amsterdam Stock Market.

Walking into the venue, you open into the “Sponsors Hall”, where all the main conference sponsors had their booths set up. It’s a huge hall with massively high ceilings, lots of cool architectural details, and tons of natural light. Very cool spot to hang out.

‍

There was also a little greenhouse with a podcast studio inside, which was neat.

‍

There were two smaller rooms for the talks.

In the entrance foyer there was a giant globe where people could stick pins to show where they’d come from.

The Ruby Embassy experience

In the upper levels, they had some open meeting/quiet work rooms, a room for lightning talks (which I didn’t really see), and a “Ruby Embassy.”

In the swag packs, they gave everyone a Ruby Passport, with the idea that you can bring it to future conferences and collect stamps.

The passport seemed like a fun, if somewhat corny, idea. But the real gem of this experience was the “Ruby Embassy” they set up in one of the rooms. They tried to make it as bureaucratic as possible, which meant that it got a bit silly.

1. The line

First, you waited in a long line.

2. The screener

Then a man in a suit with a “metal detector” (toy lightsaber, really) scanned you and checked for “contraband,” which I understood to mean anything he felt like.

3. The questionnaire

Then you had to fill out a questionnaire with questions like “How many keys do you normally have on your person?” or “What is your typical closest source of cheese?”

Due to the secure nature of the Ruby Embassy, Mike Bowman thought it best to not take photos of the questionnaire.

4. Passport photo

Then you had to take passport photos in a photo booth, followed by an interview with a government agent.

5. The Interview

The interview was tough, and the interviewers did their best to grill you about your questionnaire.

Due to the secure nature of the Ruby Embassy, Mike Bowman thought it best to not take photos of the interview process.

6. The passport

If you passed the interview (which I did), they’d approve your application and send you to the final desk where they’d glue your photo into the passport and give you a stamp.

‍

All in all, good fun.

Overall, it was a great conference. The venue was super cool, great food, excellent speakers, a nice pace with talks that didn’t drag too long and nice breaks in between, exciting announcements and future releases, and a wonderful host city in Amsterdam.