It's not Ruby that's slow, it's your database

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • prql

    PRQL is a modern language for transforming data — a simple, powerful, pipelined SQL replacement

  • SQL is powerful. A DSL that "fixes" things in this area getting all the other language feature interactions right isn't trivial, all the while users have to learn yet another language. Take PRQL for example: https://prql-lang.org. It looks nice, but the examples are very basic. What about window functions, grouping sets, lateral, DML, recursive SQL, pattern matching, pivot/unpivot etc. Might be doable, but perhaps, they've already made a decision that won't enable one of those features without adding new kludges.

    Besides, every single "fix" will be a proprietary solution, while SQL is an ISO/IEC standard that's here to stay and universally adopted.

    > A good DSL can do much better.

    Stonebraker's QUEL was "better", before SQL, and yet, where is QUEL today?

  • ruby-pg

    A PostgreSQL client library for Ruby

  • Before we proceed, are you aware that a lot of popular database drivers for Ruby (and Python? not sure) implement the performance-critical bits in good old natively compiled C?

    For example, the Ruby postgres gem: https://github.com/ged/ruby-pg/tree/master/ext

    (I wasn't sure until I checked just now, so I'm not questioning your familiarity with the tech. Just not sure if that's commonly known)

        So no, it's not the database, it's your interpreted language.

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

    WorkOS logo
  • Sidekiq

    Simple, efficient background processing for Ruby

  • I assume that Mastodon is using ActiveJob to push tasks to the queue. According to the creator of Sidekiq, bypassing ActiveJob would lead to significantly lower resource usage: https://github.com/mperham/sidekiq/wiki/Active+Job#performan...

  • FrameworkBenchmarks

    Source for the TechEmpower Framework Benchmarks project

  • While I agree with your general point (yes a Ruby web app once basic database access patterns have been optimized is essentially CPU/GVL bound), I'd advise caution when using things like techempower benchmarks of the benchmark game.

    Different languages receive very different levels of care in these, and from memory there was some big no-nos in the Rails benchmark.

    One I remember for instance is that they use redis as a cache but without a connection pool [0], and AFAICT they run puma with at least 5 threads [1], so they are very likely to content on that one Redis connection.

    That's just one of the many things I spotted when I looked at it a few months back.

    - [0] https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

    So apparently we're still discussing this and you can find variations on this article stretching back a long time https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

    Like everything engineering it really depends though, and Ruby is sadly quite slow. Twitter was rough before they replaced Rails. Most Ruby devops tools I've used have been substantially slower than tools built in other languages (e.g. Puppet vs Ansible). Ruby certainly still has value as a tool, but it should be understood to be one that isn't very performance focused.

  • hotwire-rails

    Discontinued Use Hotwire in your Ruby on Rails app

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts