Does Ruby on Rails Work With Supabase?
Ruby on Rails works excellently with Supabase as a PostgreSQL database + auth backend, requiring minimal setup and leveraging Rails' conventions naturally.
Quick Facts
How Ruby on Rails Works With Supabase
Rails integrates seamlessly with Supabase because Supabase exposes a standard PostgreSQL database—Rails' native ORM ActiveRecord connects directly without any custom adapters. You simply configure your `database.yml` with Supabase's PostgreSQL connection string, and everything works as expected: migrations, associations, validations, all standard Rails patterns apply immediately.
For authentication, you have two approaches: use Supabase Auth via the `supabase-ruby` gem for JWT-based auth (recommended for SPAs paired with Rails API), or continue using Rails' traditional session-based auth since Rails itself handles PostgreSQL user tables fine. Supabase's realtime capabilities integrate through websocket listeners in your frontend or via gems like `rails-action-cable-postgresql` if you want Rails to handle subscriptions.
The developer experience is exceptionally smooth—you get Rails conventions unchanged, PostgreSQL reliability at scale, and Supabase's hosted infrastructure removing DevOps overhead. The architecture typically treats Rails as your API/backend while Supabase handles database and optional auth, though you can also run a traditional server-rendered Rails app against Supabase without changes.
Best Use Cases
Quick Setup with Rails + Supabase
bundle add supabase-ruby dotenv# config/database.yml
default: &default
adapter: postgresql
encoding: unicode
host: <%= ENV['DB_HOST'] %>
port: 5432
database: <%= ENV['DB_NAME'] %>
username: <%= ENV['DB_USER'] %>
password: <%= ENV['DB_PASSWORD'] %>
prepared_statements: false
pool: 5
# .env
DB_HOST=your-project.supabase.co
DB_NAME=postgres
DB_USER=postgres
DB_PASSWORD=your_password
SUPABASE_URL=https://your-project.supabase.co
SUPABASE_ANON_KEY=your_anon_key
# Gemfile
gem 'supabase-ruby', '~> 1.0'
# app/models/application_record.rb (no changes needed)
class ApplicationRecord < ActiveRecord::Base
primary_abstract_class
end
# Standard Rails model—works identically
class Post < ApplicationRecord
validates :title, presence: true
endKnown Issues & Gotchas
Supabase connection pooling differs from local development; PgBouncer in transaction mode can cause issues with prepared statements
Fix: Use `prepared_statements: false` in database.yml for transaction-pooled connections, or set pool mode to 'session' if available in your Supabase tier
Row-Level Security (RLS) policies in Supabase require explicit JWT claims; Rails session auth doesn't automatically populate these claims
Fix: Either disable RLS for Rails-authenticated tables, or implement custom middleware to inject RLS claims from Rails sessions into PostgreSQL, or use Supabase Auth exclusively
Rails migrations execute with database owner role; Supabase's default postgres role has RLS-related restrictions that can fail migrations
Fix: Run migrations using a separate admin connection string, or create a dedicated migration role in Supabase with appropriate permissions
Supabase's managed backup and PITR features have retention limits on lower tiers; Rails' db:seed tasks need planning for large datasets
Fix: Monitor your tier's backup windows, run seeding during off-peak hours, and test restore procedures in staging
Alternatives
- •Firebase with Ruby on Rails (simpler auth, less control over database schema; Supabase is the better choice for Rails developers)
- •Traditional Rails with managed PostgreSQL (AWS RDS, Heroku Postgres): gives you control but requires managing backups, scaling, and credentials yourself
- •Django with Supabase: similar integration to Rails but with Django's conventions; pick based on language preference
Resources
Related Compatibility Guides
Explore more compatibility guides