Project

snowflaked

0.01
The project is in a healthy, maintained state
A Ruby gem for generating Twitter Snowflake IDs using a high-performance Rust backend. Thread-safe with configurable machine ID and custom epoch support.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
 Dependencies

Runtime

~> 0.9
>= 8.0
 Project Readme

Snowflaked

CI Gem Version Downloads License

A database-agnostic, high-performance, thread-safe Snowflake ID generator for Ruby, powered by Rust.

Snowflake IDs are 64-bit unique identifiers that encode a timestamp, machine ID, and sequence number. They're time-sortable (IDs created later are always larger), making them ideal for distributed systems where you need unique IDs without coordination between machines. Unlike UUIDs, Snowflake IDs are smaller, sortable, and index-friendly for databases.

Installation

Add to your Gemfile:

gem "snowflaked"

Quick Start

id = Snowflaked.id
# => 7193489234823847936

Rails Integration

All models automatically generate a Snowflake ID for the :id attribute:

class User < ApplicationRecord
end

User.create!
# => #<User id: 7193489234823847936>

You can also define additional Snowflake columns in migrations:

class CreateUsers < ActiveRecord::Migration[8.1]
  def change
    create_table :users do |t|
      t.snowflake :external_id
      t.bigint    :uid
    end
  end
end

Columns created with t.snowflake are automatically detected and will have Snowflake IDs generated for them.

Note

IDs are assigned in a before_create callback, so they are not available during validations and are not generated by bulk operations that skip callbacks (insert_all, upsert_all). For those, generate IDs yourself with Snowflaked.id.

Warning

SQLite does not support column comments, which Snowflaked uses to auto-detect snowflake columns other than :id. When using SQLite, you must explicitly declare snowflake columns using the snowflake_id helper in your model.

If you want to generate Snowflake IDs for additional columns, you can do so by using the snowflake_id method, without having to migrate the table:

class User < ApplicationRecord
  snowflake_id :uid
end

It is also possible to disable automatic :id generation by passing id: false to the snowflake_id method:

class Post < ApplicationRecord
  snowflake_id id: false
end

Or generate Snowflake IDs for other columns but not :id:

class Post < ApplicationRecord
  snowflake_id :external_id, id: false
end

Configuration

Snowflaked.configure do |config|
  config.machine_id = 42
  config.epoch = Time.utc(1989, 1, 3) # Defaults to DEFAULT_EPOCH (2024-01-01) if not configured
end

Configuration is locked after Snowflaked.configure or the first generated/parsed ID. Set it during application boot, before request threads start.

Machine ID

Tip

For multi-process servers like Puma in cluster mode, it is recommended to not configure machine_id explicitly. The gem derives a process-local machine ID after each fork, so every worker gets its own value.

Warning

Never share one machine_id between concurrently running processes. Each process keeps its own sequence counter, so two processes with the same machine ID that generate in the same millisecond can produce identical IDs. In particular, a fixed SNOWFLAKED_MACHINE_ID (or machine_id in the initializer) on a host running Puma in cluster mode gives every worker the same machine ID.

Auto-detection is effectively a random value between 0 and 1023 per process. With only 1024 possible values, collisions follow birthday math: at ~40 concurrent processes there is a ~50% chance that two of them share a machine ID, and beyond 1024 processes a collision is guaranteed. A shared machine ID only yields a duplicate ID when both processes generate in the same millisecond with the same sequence number — unlikely, but real at scale. Duplicates on :id are caught by the primary key (ActiveRecord::RecordNotUnique); duplicates on other snowflake columns are silent unless the column has a unique index.

If your fleet is large or duplicate IDs are unacceptable, assign explicit per-process machine IDs (e.g. derived from a pod index plus a worker index).

Machine ID Resolution

If machine_id is not explicitly configured, it resolves in this order:

  1. SNOWFLAKED_MACHINE_ID environment variable
  2. MACHINE_ID environment variable
  3. Auto-detected: a process-local value, effectively random between 0 and 1023

For Kubernetes deployments, only set an explicit machine ID if each pod runs a single generating process (e.g. Puma in single mode). A StatefulSet ordinal or pod index is then a good source of unique values:

env:
  - name: SNOWFLAKED_MACHINE_ID
    valueFrom:
      fieldRef:
        fieldPath: metadata.annotations['apps.kubernetes.io/pod-index']

With Puma in cluster mode, leave machine_id unset and let each worker derive its own.

Clock Safety

Snowflake IDs require a monotonically increasing clock. If the system clock steps backwards (NTP correction, VM migration), Snowflaked.id raises a RuntimeError instead of risking duplicate IDs, and keeps raising until the clock catches up with the last generated timestamp. Run NTP in slew mode (the default on most systems) to avoid backward steps.

API Reference

id = Snowflaked.id

Snowflaked.parse(id)
# => {timestamp_ms: 1735123456789, machine_id: 42, sequence: 0}

Snowflaked.timestamp(id)
# => 2024-12-25 12:34:56 +0000

Snowflaked.timestamp_ms(id)
# => 1735123456789

Snowflaked.sequence(id)
# => 0

Snowflaked.machine_id(id)
# => 42

Benchmarks

See BENCHMARKS.md for more details.

tl;dr: Snowflake IDs have a negligible performance impact compared to database-backed IDs.

Requirements

  • Ruby >= 3.3
  • rustc / cargo >= 1.81.0 (development uses the toolchain pinned in mise.toml)
  • Mise

Development

mise install
bundle install
bundle exec rake

Acknowledgments

License

MIT