graphql-ruby installs in two passes, and splits its feature list in three

The Rails generator leaves you needing a second bundle install

Installing the gem itself is one line in a Gemfile followed by one command:

# Gemfile
gem 'graphql'

bundle install

The Rails route is where the friction shows up. The generator is a single command:

rails generate graphql:install

After it finishes you may need to run bundle install again, because graphiql-rails is added on installation by default. That is the whole documented setup path, and it has a second step in it. If the generator is not what you want, the alternative pointer is the Getting Started page on graphql-ruby.org rather than a different command.

Six changelog files sit next to a C parser directory

The tree shows how much of this project sits outside the gem proper. There are four separate changelog files at the top level: CHANGELOG.md for the open gem, then CHANGELOG-pro.md, CHANGELOG-enterprise.md and CHANGELOG-relay.md, which means releases are tracked per audience rather than in one stream. The build and lint setup is also visible: .rubocop.yml beside a cop/ directory for project-specific cops, .rdoc_options for the generated api docs, a Rakefile, a Gemfile, graphql.gemspec and MIT-LICENSE. A graphql-c_parser/ directory sits alongside lib/, so part of the implementation is compiled rather than pure Ruby, and gemfiles/ suggests the dependency set is exercised against more than one bundle. Also present are benchmark/, spec/, guides/, javascript_client/, CNAME and the graphql-ruby.png and graphql-ruby.svg files.

Three goals, and one of them is similarity to another project

The stated goals are short enough to quote. Implement the GraphQL spec and support a Relay front end. Provide an idiomatic, plain-Ruby API with similarities to the reference implementation where possible. Support Ruby on Rails and Relay. The middle one is the interesting constraint, because the API is meant to be idiomatic plain Ruby while staying similar to the reference implementation where possible.

Persisted queries and rate limiters are sold separately

The author sells GraphQL::Pro, described as providing several features on top of the GraphQL runtime. The named list is specific: persisted queries, API versioning, streaming payloads, server-side caching, rate limiters, subscription backends for Pusher and Ably, and authorization plugins for Pundit and CanCan. Each one has its own documentation page under graphql-ruby.org, with paths such as /operation_store/overview, /changesets/overview, /defer/overview, /object_cache/overview and /limiters/overview. Pro customers also get email support and an opportunity to support the development. The two changelog files named for pro and enterprise line up with that split, which is the clearest sign in the tree that the commercial offering has its own release cadence.

Bugs go to issues with a full stack trace attached

Getting involved is split into three routes. Questions and introductions go to the graphql-ruby channel on Discord through the invite link on discord.com. Bugs go to a GitHub issue, and the ask is specific about what to include: a description, the full stack trace, and all relevant code. Actual development work is pointed at the Development guide on graphql-ruby.org, which is a separate document from Getting Started. Documentation is spread the same way: the api reference lives on rubydoc.info, the project website is graphql-ruby.org, and there is a newsletter through buttondown.email. The CNAME file in the tree is the mechanism that ties the custom domain to that site.

Five things the open gem will not do for you

Read the runtime list again with the paid list beside it. Persisted queries are not in the open gem. Neither is API versioning, so there is no changeset mechanism to hand clients. Streaming payloads are not there, which rules out incremental delivery through defer. Server-side caching is absent, so response caching has to come from somewhere else in your stack. Rate limiters are absent too, which is the sharpest gap for a public endpoint where query cost and depth are both attacker controlled. Subscription backends for Pusher and Ably and the Pundit and CanCan authorization plugins are all in the same paid list, so the open gem leaves both realtime delivery and those two authorization integrations to you.

No Ruby version requirement and no dependency list appear

What the setup instructions do not include is as telling as what they do. There is no Ruby version requirement, no minimum Rails version, and no list of runtime dependencies anywhere in the install section, so compatibility has to be settled by trying the gem against the Ruby your app already runs. The gem itself carries no version number in the install snippet, only the bare gem name. The release list also reads oddly: v1.11.12 dated 2025-07-19 appears above v1.12.4 dated 2021-02-12 and v1.12.3 dated 2021-01-29, so tags and dates do not sort into one clean line and the newest published release cannot be read off the version numbers alone. The default branch is master and the last push on it is dated 2026-10-31.

Editorial conclusion

Pick graphql-ruby when your team writes Ruby or Rails and wants to serve the GraphQL spec with an API shaped like the reference implementation. Do not pick it expecting persisted queries, server-side caching, rate limiters or Pusher and Ably subscription backends, since those are Pro features rather than part of the gem you install from RubyGems. Before committing, confirm the Ruby and Rails versions your app already pins, run the generator and then bundle install a second time because graphiql-rails is added by default, and decide whether the rate limiting a public endpoint needs has to be bought separately.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. rmosolgo/graphql-ruby on GitHub