DEV Community: kinvoki

5 Strategies for Random Records from DB

kinvoki — Mon, 03 Nov 2025 06:39:36 +0000

TLDR: I'm now using Strategy #5

Table of Contents
Why Get Random Records?
Strategy #1 - Use RANDOM()
Strategy #2 - Pluck & Array.sample
Strategy #3 - find_by with Min/Max ID
Strategy #4 - Random Offset
Strategy #5 - Where with Min/Max
Tips and Caveats
Your Thoughts?

If you've ever needed to collect a random record from a database whether using Rails or another framework/language, you may have found that there are several strategies to choose from.

Why Get Random Records?

Before we dive in, let's consider why you'd need random records at all. Random behavior is rarely desired in applications since it leads to unpredictable results. But sometimes business requirements demand it.

Common use cases include displaying random content (like a "random image" feature or "random author" on a book tracking site), or testing/debugging to catch edge cases and unexpected behavior.

Strategy #1 - Use `RANDOM()`

Use the database's built-in random function (RANDOM() for PostgreSQL/SQLite, RAND() for MySQL/MariaDB). This is the most robust approach, but slow as tables grow—around 260ms on my 1M-record test table.

Pros:

Most robust

Cons:

Gets slower as the table grows (~260ms on my 1M-record table)

Author.order('RANDOM()').limit(1)

Strategy #2 - Pluck & Array.sample

Pluck all IDs from the database and use Ruby's Array#sample to pick one at random. Faster than Strategy #1 (~50ms on 1M records), but watch out for memory consumption as tables grow.

Pros:

Faster (~50ms on 1M records)

Cons:

Gets slower as the table grows, and you may run out of memory (especially on small VMs)

Author.find(Author.pluck(:id).sample)

Strategy #3 - `find_by` with Min/Max ID

A third strategy is to generate a random ID between the minimum and maximum ID values, then use find_by to look up the record. This strategy is extremely fast, taking around 17ms on a table with 1,000,000 records, but it can be brittle if there are deleted records.

Pros:

Extremely fast if no deleted records (~17ms on my test data)
Table growth doesn't affect lookup speed

Cons:

Requires numeric, sequential IDs (no GUIDs or varchar)
Breaks with deleted records (missing IDs)
Error handling helps, but gets slower with many gaps

Author.find_by(rand(1..Author.count))

Strategy #4 - Random Offset

Use a random offset to look up a record. Not as fast (~120ms on 1M records), but works with any ID type and needs no error handling.

Pros:

No error handling needed, works with any ID type

Cons:

Slower and inconsistent: averages 120ms but varies from 20ms to 600ms depending on offset position (that's how offset works)

Author.offset(rand(1..Author.count)).limit(1)

Strategy #5 - Where with Min/Max

My preferred approach: generate a random ID between min and max values, then use a where lookup. Extremely fast (1-6ms on 1M records) and handles deleted records gracefully.

Pros:

Blazing fast: 1-6ms
Table growth doesn't affect speed (faster than offset)
Handles deleted records by finding the next available match
Chainable with other scopes (e.g., Author.published_today.random_record), though this reimplements offset behavior and may limit your data set. Still faster than using offset directly due to how offset works

Cons:

Less intuitive than offset, but offset gets slower with large datasets

# `random_id` Can be memoized / cached,
# but beware of scoping before caching(!!!)
# as you can get empty results where many are expected
random_id = rand(Author.minimum(:id)..Author.maximum(:id))
Author.where("id >= ?", random_id).limit(1)

I used to prefer Strategy #3 (even with occasional deleted records, it stayed fast). Strategy #4 also worked well. However, while answering a StackOverflow question that led to this blog post, I discovered Strategy #5—now my preferred option.

Tips and Caveats

A couple of tips to keep in mind when implementing these strategies:

Caching Author.count:

If the exact current count isn't critical, preload Author.count and memoize it (e.g., as Author.total_count), or cache it in an app-load config. This eliminates the count query overhead and speeds up Strategy #3 to under 5ms and Strategy #4 to about 100ms. Here's an example of how to do this:

def self.total_count
  @total_count ||= count
end

Be Careful with Optimizations:

However, I would warn against going crazy with optimizations here, such as caching min/max values, as depending on the context, scoping, etc, it may lead to unexpected results. If you use Strategy #5, the bottleneck won't be in the database, so making 3 quick queries is preferable, unless it really-really matters for your WebScale™ app.

Error Handling:

For error handling, you have two options: retry lookups until finding an existing record, or do multiple Strategy #3 lookups and randomly select from the results. Depending on how many gaps you have in your data set, Strategy #3 may not be the best choice.

Your Thoughts?

Did I miss any approaches, or made a glaring blunder? Please, comment and let me know :)

Originally published: February 20, 2024 • Last updated: January 15, 2025

Cross-published from my blog: https://kinvoki.com/programming/5-strategies-random-records-from-db/

Valentine's Day Equation Plotted in Ruby

kinvoki — Mon, 03 Nov 2025 06:39:20 +0000

TLDR: Use Ruby and GNUPlot to plot the mathematical Valentine's Day heart equation. Perfect for teaching kids programming through something they relate to.

I'm trying to expose my kids to programming bit by bit. 😊 Things that work the best are something that they relate to. Almost right on cue, this blog post came up on my feed on dev.to on Saturday and I thought it would be a fun activity to help kids make Valentines in a new way. Thank you, @DevLorenz0 for the formula! ❤️

All you need is Ruby & GNUPlot, and possibly GNUPlot official docs PDF if you want to experiment further.

Installation

# on Mac
brew install gnuplot
gem install gnuplot

# Chocolatey has a package for Windows
# choco install gnuplot

# Use rpm / apt on Linux
# apt-get install gnuplot

The Code

# valentine_day_plot.rb
# Tested on Ruby 2.7.2
require 'rubygems'
require 'gnuplot'

valentines_day_function = lambda { |t|
  x = 16 * Math.sin(t)**3
  y = 13 * Math.cos(t) - 5 * Math.cos(2 * t) - 2 * Math.cos(3 * t) - Math.cos(4 * t)
  # Experimentally found that rounding to 4
  # produces the best results for us
  [x.round(4).to_f, y.round(4).to_f]
}

# Adjust this to get more or less number of plot points
# At the end we transpose array, to shape data for
# Gnuplot::DataSet input below
DISTANCE_BETWEEN_POINTS = 0.0001
COORDINATES = (0..(2 * Math::PI)).step(DISTANCE_BETWEEN_POINTS)
                                 .to_a
                                 .map do |t|
  valentines_day_function.call(t)
end.transpose

Gnuplot.open do |gp|
  Gnuplot::Plot.new(gp) do |plot|
    plot.output 'valentine_day_plot.pdf'
    # Sized as a nice square to be printed on a A4 or US Letter page
    plot.terminal 'pdf colour size 8in,8in'

    # The following is self-explanatory, but setting range too small,
    # will put the graph out of bounds
    plot.xrange '[-20:20]'
    plot.yrange '[-20:20]'
    plot.title  "Valentine's Day Equation"
    plot.ylabel 'Love-y'
    plot.xlabel 'Love-x'

    # DataSet.new can also take the formula directly, not just an array
    # of shape [x-coordinates, y-coordinates]
    plot.data << Gnuplot::DataSet.new(COORDINATES) do |ds|
      # You can also draw graph using various other types,
      # 'linespoints','steps','fillsteps', etc
      # See http://www.gnuplot.info/docs_5.4/Gnuplot_5_4.pdf
      # for full docs
      ds.with = 'lines'
      ds.linewidth = 15
      # Change this to the name of your Valentine
      ds.title = 'My Valentine'
    end
  end
end

The Result

Here is an example of the plotted graph if we change DISTANCE_BETWEEN_POINTS = 0.1 and ds.with = 'steps' and ds.linewidth = 1:

Bonus: Converting to Image Formats

The PDF we generated above is perfect for printing, but if you wanted to convert it to a JPEG or PNG, you can use a graphics app like Photoshop or GIMP, or simply use ImageMagick:

# Install it if you don't have it
brew install imagemagick
convert -quality 300 -density 300 valentine_day_plot.pdf valentine_day_plot.jpg

Resources

Last updated: February 15, 2021

Originally published: February 15, 2021 • Last updated: January 25, 2025

Cross-published from my blog: https://kinvoki.com/programming/valentines-day-equation-plotted-in-ruby/

Upgrading to GitLab 15.0 CE from GitLab 14.9.3

kinvoki — Mon, 03 Nov 2025 06:35:45 +0000

TLDR: GitLab won't let you upgrade directly from 14.9.3 to 15.0. You must upgrade to 14.10.x first, then to 15.0.

Every time I need to upgrade to the next big GitLab CE release, I end up jumping through hoops, looking for specific steps or going through .bash_history to see what I've done in the past. This is a small self-note on what to do next time.

The Problem

So running my usual update commands:

sudo apt update -y; sudo apt upgrade -y; sudo apt autoremove -y;

Led me to a cryptic message:

Preparing to unpack .../gitlab-ce_15.0.0-ce.0_amd64.deb ...
gitlab preinstall: It seems you are upgrading from major version 14 to major version 15.
gitlab preinstall: It is required to upgrade to the latest 14.10.x version first before proceeding.
gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/index.html#upgrade-paths
dpkg: error processing archive /var/cache/apt/archives/gitlab-ce_15.0.0-ce.0_amd64.deb (--unpack):

However, I'm running 14.9.3 which is pretty recent, considering that I update my machines every few weeks. The confusing part here is that there are no simple instructions in the error message or on the support website as to what to do next. The more confounding thing is, that support website doesn't even mention version 14.10 as an option.

The support link outlines the upgrade path and which versions to use, **but not how to do it.

The Solution

⚠️ Warning

The following command was executed on a system that was FULLY backed up using both GitLab backup process and a VM snapshot.

Do this at your own risk 😳

Well, turns out it's actually very simple on Ubuntu/Debian using apt for my GitLab:

Step 1: Upgrade to 14.10.x

# First I removed old backups that were taking up a lot of space
# from /var/opt/gitlab/backups/
sudo apt upgrade -y gitlab-ce=14.10.0-ce.0

This process may take a bit of time depending on how fast your VM is & how big your GitLab install is. Took about 15 mins for me.

🔑 Key Thing

If you need to upgrade from an earlier version of GitLab - the same steps apply. You just need to follow the upgrade path outlined on the support website.

And NO you CANNOT skip steps, the result will be unpredictable.

Pro tip: GitLab has a convenient Upgrade Path tool that shows you exactly which versions to upgrade through.

Step 2: Upgrade to 15.0

Now we're all ready to install the latest GitLab CE, which can be done using a general command like so, if you like to risk it all:

sudo apt update -y; sudo apt upgrade -y; sudo apt autoremove -y;

Or simply:

sudo apt upgrade -y gitlab-ce

Don't Panic

P.S.: Don't forget to reboot.

P.P.S.: Reminder to Future Me - don't freak out if you see a 500 error response. GitLab takes 3-5 mins to fully come up after a full reboot.

Resources

GitLab Upgrade Paths Documentation
GitLab Upgrade Path Tool (shows exact upgrade sequence)
GitLab Backup Process

Last updated: May 24, 2022

Originally published: May 24, 2022 • Last updated: January 22, 2025

Cross-published from my blog: https://kinvoki.com/programming/upgrading-to-gitlab-15-from-14/

Lucky is Lightning Fast!

kinvoki — Mon, 03 Nov 2025 06:34:05 +0000

TLDR: Lucky Framework (Crystal) ranks near the top in TechEmpower Benchmark #20, competing strongly against full-stack frameworks like Rails, Phoenix, and Django.

TechEmpower just posted Round #20 of their Web Framework benchmarks and Lucky Framework (that runs on Crystal Language) is in it, thanks to work done by @matthewmcgarvey (Great job on the benchmark!).

Pretty solid result! Especially if you only consider "Full-stack" frameworks and not micro-stuff.

Key Takeaways

1. Lucky is near the top in Crystal-land (and beyond)

In the Crystal ecosystem, Lucky ranks near the top. And in the broader web framework landscape too.

2. Crystal frameworks dominate speed

The main speed-competitor in Crystal-land is Raze framework (which has been retired). Lucky's speed is comparable to most other Crystal frameworks: Kemal, Spider-Gazelle, Onyx & Amber (all did pretty well on speed thanks to Crystal 😊)

3. Lucky holds its own against full-featured frameworks

The most important comparison for me is against true full-featured frameworks like Rails, Hanami, Phoenix, Django, Symphony, Grails, Spring, Prologue, etc. And Lucky is doing really well there.

Filtering the Noise

If you go to the main page, there are ~250 benchmark results for every web-framework under the sun. However, that's too many results for my taste 😊 i.e. things like "h2o.cr" on the list are too purpose-specific for me or anything I would do in a normal course of things, developing an enterprise or user-facing web application.

I'm currently considering a Full-Stack Framework for a small web-based enterprise-type project and deciding between Phoenix, Lucky & Rails. Each has its own strengths for my use-case. So this particular comparison is more of an interest to me, based on frameworks & languages that I've had exposure to or would even consider for such an application.

Take a look at the benchmark, and I hope you give Lucky Framework a spin.

Disclaimer

⚠️ Take These Benchmarks with a Grain of Salt

Not all frameworks are properly optimized - Some frameworks on the list may not be configured for optimal performance

Speed is only one aspect - Performance should be one consideration among many

Ecosystem matters more - Ecosystem, dev experience, and productivity are all more important than speed in most cases

Having said that ☝️ - Lucky ticks all 3 boxes for me

Resources

Last updated: February 9, 2021

Originally published: February 08, 2021 • Last updated: February 09, 2021

Cross-published from my blog: https://kinvoki.com/programming/lucky-framework-lightning-fast-benchmarks/

When FTP Stands for Frustrating Transfer Problem

kinvoki — Mon, 03 Nov 2025 06:33:38 +0000

TLDR: After 5 hours of troubleshooting FTP over OpenVPN, the solution was enabling compression—the exact opposite of what everyone recommended.

Let's talk about FTP file transfers, shall we? Picture this: A typical day, armed with FileZilla (for adhoc testing) and a Ruby script employing Net::FTP gem, tasked with the simple job of uploading files to a remote ProFTPD server. Sounds like a snooze-fest, right? Oh, how wrong you'd be!

In the office, everything was smooth sailing. File uploads were as effortless as breathing. But from home, connected through OpenVPN, I was greeted with an error so cryptic it might as well have been written in hieroglyphics:

Net::FTPTempError: 450 Transfer aborted. Link to file server lost.

And so began my descent into the swirling vortex of troubleshooting. pfSense firewall settings, NAT configurations, FTP server settings—everything was under scrutiny.

5 Hours In...

I tried every trick in the book:

Switching between active and passive FTP
Peering into the soul of the OpenVPN configuration
Allowing ALL traffic between LAN & OpenVPN (a big no-no)
Trying every possible permission configuration
ProFTPd config changes
Even blaming poor FileZilla for a hot second

But alas! I was no closer to a solution.

Yes. This too was not out of the question.

The Ghost Files

Oh, and let's not forget the ghost files! Every failed attempt at uploading a file would result in the creation of a zero-sized file on the server. It was like the server was pointing and laughing at me, creating an empty shell of a file, a cruel reminder of my predicament.

The Plot Twist

Just when I was about to call it a day and accept defeat, I stumbled upon a tidbit of advice:

"Some VPN configurations may have compression enabled, which can cause issues with certain types of traffic. You can try disabling compression on your OpenVPN configuration to see if it resolves the issue."

I thought to myself, "Could it be that simple?"

But wait! Plot twist! My OpenVPN configuration already had compression disabled.

So, in an act of sheer desperation, I decided to go against the grain. I enabled compression, held my breath, and...

Eureka! It worked. I kid you not. It worked faster too!

The Lesson

So there you have it, folks. The thrilling saga of FTP troubleshooting, where the hero turns out to be the unsuspecting compression feature, the very thing that was supposedly the villain of the piece. Just goes to show, when it comes to networking, expect the unexpected.

If there's a moral to this story, it's this: The answer might not always be where you expect it to be. And sometimes, you just gotta switch things on instead of off.

So, here's to more head-scratching adventures in the world of IT. Because let's face it, we wouldn't have it any other way!

Happy troubleshooting!

Originally published: May 13, 2024 • Last updated: January 18, 2025

Cross-published from my blog: https://kinvoki.com/programming/when-ftp-stands-for-frustrating-transfer-problem/

Functional Ruby Programming with Trailblazer

kinvoki — Mon, 03 Nov 2025 06:25:33 +0000

You might be surprised to learn that you're already using many functional programming (FP) approaches in your Ruby code without realizing it. While languages like Haskell enforce these principles, Ruby and Python leave it up to the programmer to make conscious choices. Let's explore how we can leverage these FP concepts in Ruby, particularly when using the Trailblazer (TRB) framework.

Key Functional Programming Concepts in Ruby and Trailblazer

1. Embrace Immutability

In Trailblazer, we treat incoming data as immutable. The only mutable data structure is the internal hash (options[:my_key] or ctx[:my_other_key] in TRB 2.1). When transforming data, always assign the result to a new key instead of modifying in place:

def transform_data(ctx, input_array:, **)
  ctx[:transformed_array] = input_array.map { |item| item.upcase }
end

Consider using gems like Hamster for immutable data structures, or simply maintain self-discipline in your approach.

2. Simplify Function Signatures

Keep your method signatures simple, limiting them to 2-4 attributes. This practice enhances testability and reduces code complexity. For most Trailblazer steps, this structure suffices:

def my_step(ctx, params:, **)
  # Your logic here
end

Take advantage of named parameters and default values when applicable.

3. Break Down Complex Operations

Divide your methods, steps, and operations into smaller, more manageable units. This approach may require more initial setup but pays dividends in maintainability and composability. Treat your Trailblazer operations as functional objects:

class CreateUser < Trailblazer::Operation
  step :validate
  step :persist
  step :send_welcome_email

  # Each step is a small, focused function
end

4. Eliminate External State

Ensure your operations receive everything they need when called, avoiding reliance on global or external state. This doesn't preclude the use of global configs, but their values should be provided explicitly:

result = CreateUser.(params: user_params, config: AppConfig)

5. Leverage Trailblazer's Functional Design

Trailblazer is built with functional concepts in mind. Many steps can be implemented as lambda functions, embracing a pure functional approach:

class UpdateProfile < Trailblazer::Operation
  step ->(ctx, params:, **) { params[:name].present? }
  # More steps...
end

6. Consider Adding Type Checking

While Ruby is dynamically typed, you can add type checking to your codebase using gems like Sorbet, RBS, Dry-Types or Literal. This can help catch errors early and improve code clarity:

# Using Sorbet
require 'sorbet-runtime'

class User
  extend T::Sig

  sig { params(name: String, age: Integer).void }
  def initialize(name, age)
    @name = name
    @age = age
  end
end

7. Implement Lazy Evaluation

For large data structures, consider using lazy evaluation to improve performance:

large_collection = (1..1_000_000).lazy.map { |n| n * 2 }.select(&:even?)

Many of these functional programming principles are likely already part of your Ruby toolkit, even if you haven't explicitly labeled them as such. By consciously applying these concepts, especially when working with Trailblazer, you can write more maintainable, testable, and robust code.

Remember, while Ruby may not be Haskell, it offers the flexibility to incorporate functional programming paradigms alongside its object-oriented nature. Embrace this hybrid approach to level up your Ruby and Trailblazer projects!

Originally published: November 29, 2018 • Last updated: January 20, 2025

Cross-published from my blog: https://kinvoki.com/programming/functional-programming-with-trailblazer/

Ruby Hash - String Keys Vs Symbol Keys

kinvoki — Mon, 03 Nov 2025 06:12:09 +0000

There was recently a discussion on Trailblazer Gitter channel about Hashes as params, how to pass them around, and as customary a flame-war war ~~insued~~ never happened, and it came down to a measuring contest: ~~whose~~ which key is better and faster.

TLDR;

For small hashes it doesn’t really matter, for larger ones :symbol is 1.15x faster than string’ keys. Frozen string’ keys are in-between.

The best way to argue, is to present facts. So I coded a couple of benchmarks, and submitted a pull request to fast-ruby (Github). Here are the details.

Round 1: Hash[:symbol] vs Hash[“string”]

First lets measure allocating Hash in various ways that Ruby gives us

require "benchmark/ips"

def symbol_key
  {symbol: 42}
end

def symbol_key_arrow
  {:symbol => 42}
end

def symbol_key_in_string_form
  {'sym_str': 42}
end

def string_key_arrow_double_quotes
  {"string" => 42}
end

def string_key_arrow_single_quotes
  {'string' => 42}
end


Benchmark.ips do |x|

  puts "Hash comparison"
  x.report( %({symbol: 42} )){ symbol_key }
  x.report( %({:symbol => 42} )) { symbol_key_arrow }
  x.report( %({'sym_str': 42} )) { symbol_key_in_string_form }
  x.report( %({"string" => 42} )) { string_key_arrow_double_quotes }
  x.report( %({'string' => 42} )) { string_key_arrow_single_quotes }
  x.compare!
end

Hash comparison
ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [arm64-darwin25]
Warming up --------------------------------------
       {symbol: 42}    807.478k i/100ms
    {:symbol => 42}      1.070M i/100ms
    {'sym_str': 42}      1.083M i/100ms
   {"string" => 42}      1.075M i/100ms
   {'string' => 42}      1.047M i/100ms
Calculating -------------------------------------
       {symbol: 42}      10.776M (± 9.0%) i/s   (92.80 ns/i) -     53.294M in   5.010967s
    {:symbol => 42}      10.921M (± 4.1%) i/s   (91.56 ns/i) -     54.591M in   5.007897s
    {'sym_str': 42}      10.703M (± 9.3%) i/s   (93.44 ns/i) -     53.090M in   5.023091s
   {"string" => 42}      10.543M (± 9.8%) i/s   (94.85 ns/i) -     52.653M in   5.063165s
   {'string' => 42}      10.561M (±10.0%) i/s   (94.69 ns/i) -     52.338M in   5.024881s

Comparison:
    {:symbol => 42} : 10921358.3 i/s
       {symbol: 42} : 10775503.9 i/s - same-ish: difference falls within error
    {'sym_str': 42} : 10702520.9 i/s - same-ish: difference falls within error
   {'string' => 42} : 10560679.5 i/s - same-ish: difference falls within error
   {"string" => 42} : 10543355.5 i/s - same-ish: difference falls within error

Used to be a difference on Ruby 2.*, but running benchmark on Ruby 3.4.7 - we can see that style doesn’t really matter. Using string "42" for values instead of number 42, will slightly change the benchmark, but insignificant in the grand scheme of things.

Don’t overcomplicate

string keys are not going to be the speed bottleneck in your app

Round 2: But what about large hashes?

Don’t worry I got you covered. Lets try it out for a 1000 key-value pairs.

require "benchmark/ips"


STRING_KEYS = (1001..2000).map{|x| "key_#{x}"}.shuffle
FROZEN_KEYS = (2001..3000).map{|x| "key_#{x}".freeze}.shuffle
SYMBOL_KEYS = (3001..4000).map{|x| "key_#{x}".to_sym}.shuffle

# If we use static values for Hash, speed improves even more.
def symbol_hash
  SYMBOL_KEYS.collect { |k| [ k, rand(1..100)]}.to_h
end

def string_hash
  STRING_KEYS.collect { |k| [ k, rand(1..100)]}.to_h
end

# See this article for the discussion of using frozen strings instead of symbols
# http://blog.arkency.com/could-we-drop-symbols-from-ruby/
def frozen_hash
  FROZEN_KEYS.collect { |k| [ k, rand(1..100)]}.to_h
end


SYMBOL_HASH = symbol_hash
STRING_HASH = string_hash
FROZEN_HASH = frozen_hash


def reading_symbol_hash
  SYMBOL_HASH[SYMBOL_KEYS.sample]
end

def reading_string_hash
  STRING_HASH[STRING_KEYS.sample]
end

def reading_frozen_hash
  FROZEN_HASH[FROZEN_KEYS.sample]
end

Benchmark.ips do |x|

  puts "Creating large Hash"
  x.report("Symbol Keys") { symbol_hash }
  x.report("String Keys") { string_hash }
  x.report("Frozen Keys") { frozen_hash }

  x.compare!
end

Benchmark.ips do |x|
  puts "Reading large Hash"
  x.report("Symbol Keys") { reading_symbol_hash }
  x.report("String Keys") { reading_string_hash }
  x.report("Frozen Keys") { reading_frozen_hash }
  x.compare!
end

Let’s see the results:

Creating large Hash
ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [arm64-darwin25]
Warming up --------------------------------------
         Symbol Keys   816.000 i/100ms
         String Keys   541.000 i/100ms
         Frozen Keys   723.000 i/100ms
Calculating -------------------------------------
         Symbol Keys      7.759k (± 8.5%) i/s  (128.88 μs/i) -     38.352k in   5.005736s
         String Keys      5.716k (± 4.8%) i/s  (174.96 μs/i) -     28.673k in   5.030225s
         Frozen Keys      7.411k (± 8.3%) i/s  (134.93 μs/i) -     36.873k in   5.037710s

Comparison:
         Symbol Keys:     7759.1 i/s
         Frozen Keys:     7411.3 i/s - same-ish: difference falls within error
         String Keys:     5715.6 i/s - 1.36x  slower

Reading large Hash
ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [arm64-darwin25]
Warming up --------------------------------------
         Symbol Keys     1.373M i/100ms
         String Keys   930.582k i/100ms
         Frozen Keys     1.205M i/100ms
Calculating -------------------------------------
         Symbol Keys     13.467M (± 7.6%) i/s   (74.26 ns/i) -     67.269M in   5.046055s
         String Keys     11.345M (± 1.7%) i/s   (88.14 ns/i) -     56.766M in   5.005134s
         Frozen Keys     11.820M (± 8.8%) i/s   (84.60 ns/i) -     59.025M in   5.068781s

Comparison:
         Symbol Keys: 13466641.7 i/s
         Frozen Keys: 11819675.1 i/s - same-ish: difference falls within error
         String Keys: 11344986.8 i/s - 1.19x  slower

So as we can see on a larger Hashes with with 1000's of keys, the difference become more apparent and being mindful of it can help improve speed, if you are using a lot of large hashes. Otherwise, keep using what works better for you app. If string keys make it easier, let's say you are importing them from an external file, don't go through the trouble of converting them to symbols, it's probably not worth it.

But don't take my word for it. Just measure it.

Originally published: October 27, 2017 • Last updated: November 01, 2025

Cross-published from my blog: https://kinvoki.com/programming/ruby-string-vs-symbol-keys/

DEV Community: kinvoki

5 Strategies for Random Records from DB

Table of Contents

Why Get Random Records?

Strategy #1 - Use RANDOM()

Strategy #2 - Pluck & Array.sample

Strategy #3 - find_by with Min/Max ID

Strategy #4 - Random Offset

Strategy #5 - Where with Min/Max

Tips and Caveats

Your Thoughts?

Valentine's Day Equation Plotted in Ruby

Installation

The Code

The Result

Bonus: Converting to Image Formats

Resources

Upgrading to GitLab 15.0 CE from GitLab 14.9.3

The Problem

The Solution

⚠️ Warning

Step 1: Upgrade to 14.10.x

🔑 Key Thing

Step 2: Upgrade to 15.0

Don't Panic

Resources

Lucky is Lightning Fast!

Key Takeaways

Filtering the Noise

Disclaimer

⚠️ Take These Benchmarks with a Grain of Salt

Resources

When FTP Stands for Frustrating Transfer Problem

5 Hours In...

The Ghost Files

The Plot Twist

The Lesson

Functional Ruby Programming with Trailblazer

Key Functional Programming Concepts in Ruby and Trailblazer

1. Embrace Immutability

2. Simplify Function Signatures

3. Break Down Complex Operations

4. Eliminate External State

5. Leverage Trailblazer's Functional Design

6. Consider Adding Type Checking

7. Implement Lazy Evaluation

Ruby Hash - String Keys Vs Symbol Keys

TLDR;

Round 1: Hash[:symbol] vs Hash[“string”]

Don’t overcomplicate

Round 2: But what about large hashes?

Strategy #1 - Use `RANDOM()`

Strategy #3 - `find_by` with Min/Max ID