This content originally appeared on DEV Community and was authored by Alex Aslam
"We ran Rails in AWS Lambda—and lived to tell the tale."
Serverless promises zero infrastructure, infinite scale, and pay-per-use pricing. But when we tried running a Rails app with ActiveRecord on Jets, we hit walls you won’t find in the docs.
Here’s what worked, what catastrophically failed, and how we fixed it.
1. The Dream vs. The Reality
What We Expected
✅ No servers to manage
✅ Automatic scaling during traffic spikes
✅ Cost savings (only pay for execution time)
What We Got
❌ Cold starts (5+ seconds for the first request)
❌ Database connection storms (Lambda + ActiveRecord = 💥)
❌ Mysterious timeouts (Rails + 15-second Lambda limit = 😱)
2. The 3 Big Breakages (And Fixes)
Breakage #1: Database Connections
Problem:
- Each Lambda instance opens new ActiveRecord connections
- Connection pool exhaustion under load
Fix:
# config/initializers/lambda_db.rb
if ENV["AWS_LAMBDA_FUNCTION_NAME"]
ActiveRecord::Base.establish_connection(
pool: 1, # One connection per Lambda instance
checkout_timeout: 2 # Fail fast
)
end
Lesson: Serverless ≠ Stateless. ActiveRecord assumes persistent processes.
Breakage #2: Cold Starts
Problem:
- First request loads entire Rails app (500ms-5s delay)
Fix:
- Pre-warm Lambdas with scheduled CloudWatch Events
- Trim Rails:
# config/application.rb
require "active_record/railtie"
require "action_controller/railtie"
# Skip unused frameworks (ActionMailer, etc.)
Lesson: Rails is heavy. Serverless favors minimalist stacks.
Breakage #3: Background Jobs
Problem:
-
delayed_job/sidekiqdon’t work in Lambda’s ephemeral world
Fix:
- Replace with Lambda-triggered jobs:
# app/jobs/email_job.rb
def self.process(event, context)
UserMailer.welcome(event["user_id"]).deliver_now
end
- Or use SQS + Lambda (Jets has built-in support)
Lesson: Serverless demands event-driven workflows.
3. What Actually Worked Well
1. API Endpoints
- Jets + API Gateway handled 10K RPM smoothly
- No scaling headaches during traffic spikes
2. Async Processing
- S3 uploads → Lambda processors worked flawlessly
- Cost dropped 70% vs. always-on workers
3. Admin Tools
- Serverless Rails Admin (read-only) saved $800/month vs. EC2
4. When to Avoid Serverless Rails
🚫 Real-time apps (WebSockets don’t play nice with Lambda)
🚫 Heavy ActiveRecord usage (migrations, complex transactions)
🚫 Legacy monoliths (too much refactoring needed)
Golden Rule:
Use serverless for new, event-driven workflows—not to lift-and-shift old Rails apps.
"But Heroku Is Easy!"
It is—until you hit scale or cost walls. Serverless Rails isn’t for everyone, but when it fits:
-
Start with one endpoint (e.g.,
/api/webhooks) - Measure cold starts
- Expand cautiously
Tried serverless Rails? Share your horror stories or wins below.
This content originally appeared on DEV Community and was authored by Alex Aslam
Alex Aslam | Sciencx (2025-06-25T22:59:29+00:00) Rails on Jets: Serverless Active Record? Here’s What Broke. Retrieved from https://www.scien.cx/2025/06/25/rails-on-jets-serverless-active-record-heres-what-broke/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.