Does Ruby on Rails Work With Turso?
You can use Turso with Rails, but it requires custom setup since Rails' ActiveRecord doesn't natively support libSQL; you'll need the turso gem or raw HTTP clients.
Quick Facts
How Ruby on Rails Works With Turso
Rails applications can connect to Turso databases, but not through the standard ActiveRecord adapters. The primary approaches are: (1) using the community-maintained `turso` gem which provides a thin wrapper around libSQL's HTTP API, (2) using the official Turso JavaScript SDK via a sidecar or API layer, or (3) executing raw SQL through HTTP requests. Rails' ActiveRecord is built around traditional SQL drivers (PostgreSQL, MySQL, SQLite), and while Turso is SQLite-compatible, it's edge-hosted and accessed via HTTP/REST, not traditional TCP connections. This means you lose some ActiveRecord conveniences like automatic schema migrations in the traditional sense—you'll need to manage schema changes through Turso's CLI or migration tools separately. For simple CRUD operations with basic associations, the developer experience is reasonable once configured, but complex polymorphic relationships or advanced Rails ORM features may require manual SQL. The edge-distributed nature of Turso makes it excellent for Rails apps serving global audiences with low-latency reads, but writes still route through the primary region.
Best Use Cases
Quick Setup with turso gem
gem 'turso', '~> 0.1.0'# Gemfile
gem 'turso'
# config/initializers/turso.rb
Turso.configure do |config|
config.database_url = ENV['TURSO_DATABASE_URL']
config.auth_token = ENV['TURSO_AUTH_TOKEN']
end
# app/models/post.rb
class Post
include Turso::Model
table_name :posts
attributes :id, :title, :body, :created_at
end
# In your controller or service
@posts = Post.all
@post = Post.find(1)
Post.create(title: 'Hello', body: 'World')Known Issues & Gotchas
ActiveRecord adapters don't exist for libSQL; you must use HTTP client gems or raw queries
Fix: Use the `turso` gem (github.com/tursodatabase/turso-client-ruby) or implement a custom database adapter; migrations require Turso CLI, not Rails generators
Write latency is higher than local SQLite because all writes go to primary region
Fix: Design your schema and access patterns for read-heavy workloads; batch writes when possible and consider async job queues for non-critical operations
Connection pooling and transaction semantics differ from traditional SQL adapters
Fix: The HTTP-based connection model doesn't support persistent connections; use connection pooling at the HTTP client level and be cautious with long-running transactions
Rails scaffolds, migrations, and fixtures don't work out-of-the-box
Fix: Write migrations manually via Turso CLI (turso db shell) or use raw SQL files; this is actually fine for most teams but breaks Rails convention
Alternatives
- •PostgreSQL on AWS RDS + Rails ActiveRecord (traditional, fully-featured but less edge-optimized)
- •PlanetScale (MySQL-compatible) + Rails ActiveRecord (good global distribution with native ActiveRecord support)
- •Supabase (PostgreSQL + serverless functions) + Rails (full Rails compatibility with edge functions for custom logic)
Resources
Related Compatibility Guides
Explore more compatibility guides