██FR█████ █INTELL███████████

Rails on Jets: Serverless Active Record? Here’s What Broke


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/sidekiq don’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:

  1. Start with one endpoint (e.g., /api/webhooks)
  2. Measure cold starts
  3. 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