SYSTEM Cited by 6 sources

Ruby on Rails

Ruby on Rails is the dominant Ruby web-application framework (David Heinemeier Hansson, 2004). Canonical MVC web framework with ActiveRecord ORM, convention-over-configuration defaults, and a large ecosystem of companion gems for background jobs (Sidekiq), feature flags (Flipper), testing (Minitest / RSpec / FactoryBot), and SAML auth (ruby-saml).

Why it matters here

PlanetScale's application-tier backend is a Rails monolith. Multiple Rails-specific engineering posts have surfaced on the wiki:

• Rails klass.underscore convention used as the stable key for feature-flagged job-enqueue rejection naming.
• Rails test-suite parallelism (parallelize(workers: N)) as the CI feedback-loop speedup lever.
• FactoryBot factories as the fixture-library substrate + the object-explosion failure mode that goes with it.

Rails is also the substrate most SidekiqMiddleware::* code lives in — client middleware runs inside Rails request processes (or console sessions or rake tasks), server middleware inside Sidekiq worker processes that boot the same Rails app.

Seen in

• sources/2026-04-21-planetscale-identifying-slow-rails-queries-with-sqlcommenter — canonical wiki introduction of Rails 7's query_log_tags native feature + the ActiveRecord annotate per-query method + PlanetScale's activerecord-sql_commenter gem that swaps the Rails-default tag format for SQLCommenter. Also surfaces the Marginalia gem as the Rails-6-and-earlier pre-history of the framework-absorbed feature. Together these establish Rails as the canonical ORM-layer-query-tag-propagation substrate on the wiki (patterns/query-comment-tag-propagation-via-orm).
• sources/2026-04-21-planetscale-how-to-kill-sidekiq-jobs-in-ruby-on-rails — Rails .underscore class-name convention used to derive per-job-class Flipper flag names (InvoiceJob → disable_invoice_job).
• sources/2026-04-21-planetscale-how-our-rails-test-suite-runs-in-1-minute-on-buildkite — Rails test-suite parallelism + FactoryBot audit on CI.
• sources/2026-04-21-planetscale-how-we-made-planetscales-background-jobs-self-healing — Rails substrate for PlanetScale's self-healing-Sidekiq architecture: ActiveRecord with_lock (row-level SELECT FOR UPDATE), in_batches cursor iteration for bulk scheduler enqueue, ActiveJob's set(wait:).perform_later API composed into perform_with_jitter on ApplicationJob. The scheduler pattern and idempotent-job discipline sit on top of these Rails-framework primitives.

Related

• systems/sidekiq
• systems/flipper-gem
• systems/ruby-saml
• systems/activerecord-sql_commenter
• systems/marginalia-gem
• systems/fastpage-gem
• systems/mysql
• systems/innodb
• concepts/feature-flag
• concepts/factorybot-object-explosion
• concepts/rails-query-log-tags
• concepts/activerecord-annotate
• concepts/sqlcommenter-query-tagging
• concepts/offset-pagination-cost
• concepts/deferred-join
• concepts/cursor-pagination
• patterns/query-comment-tag-propagation-via-orm
• patterns/deferred-join-for-offset-pagination
• patterns/conditional-optimization-by-page-depth

Seen in — ActiveRecord query-rewriter gems

• sources/2026-04-21-planetscale-introducing-fastpage-faster-offset-pagination-for-rails-apps — Mike Coutermarsh's 2022 introduction of PlanetScale's fast_page gem. Rails is the substrate for the ORM-level SQL-rewriter gem pattern: a method added to ActiveRecord::Relation mechanically transforms a query chain into a more efficient equivalent — here, the deferred-join rewrite for deep-offset pagination. The post's canonical usage pattern is Rails-idiomatic method-chain composition: Post.all.order(created_at: :desc).limit(25).offset(100).fast_page. Cross-ecosystem companion: Hammerstone's Laravel fast-paginate gem implements the same rewrite for Eloquent. Both gems confirm the broader observation that the ORM-query-rewriter pattern is ecosystem-portable — the rewrite is SQL-level, the gem is just the ergonomic wrapper.

Seen in — multi-database config + automatic role switching

• sources/2026-04-21-planetscale-introducing-planetscale-portals-read-only-regions — Taylor Barnett's PlanetScale Portals launch uses Rails' multiple-databases / automatic role switching as the canonical application-side integration for a read- write-split + regional read replica architecture. Three Rails-specific mechanisms are load-bearing in the post:

• database.yml multi-connection — primary (write connection) + primary_replica (read connection with replica: true). Rails treats primary_replica as a read-only sibling of primary for monitoring / migration purposes.

• connected_to(role: :reading) do … end — explicit per-block routing for code that wants to force replica reads.
• ActiveRecord::Middleware::DatabaseSelector with { delay: 2.seconds } — automatic role switching. Reads go to primary_replica by default; after any write, a session cookie pins the user's reads back to primary for 2 seconds, preserving read-your-writes.

The Rails invocation is the canonical framework-level shape of the patterns/session-cookie-for-read-your-writes pattern — see that pattern page for the full recipe and equivalents in Django / Laravel / plain-driver apps. Code acknowledgment to Mike Coutermarsh (same PlanetScale-Rails engineer voice as the FastPage / SQLCommenter / self-healing- Sidekiq posts).