Plan worker IDs and shard IDs inside a Snowflake-style lane pool, size the bit split from real capacity needs, pack example lane values.
Last updated
Plan worker IDs and shard IDs before you burn them into a generator Use this worker ID / shard ID generator when you need to size a Snowflake-style lane pool, check whether a split really fits, pack shard and worker values into one low-bit integer, and validate existing lane values.
Preset
Planning mode
5 / 5
Shard / worker bits
32
Max shards
32
Workers per shard
1,024
Packed lane values
Minimum bits
Shards: 4 bits
Workers: 4 bits
Capacity request fits in the selected pool.
Masks
Shard mask: 0x3E0 / 1111 1000 00
Worker mask: 0x1F / 0000 0111 11
Spare headroom
1 spare bit
In capacity mode, spare bits stay on the worker side so you can see the real per-shard headroom after the minimum shard split is satisfied.
Packed example
103
Shard 3, worker 7
Binary 0001 1001 11
Hex 0x67
Packed value inspector
103
Decoded shard 3, worker 7
Binary 0001 1001 11
Hex 0x67
Allocation warnings and caveats
A 10-bit lane pool is common for classic Snowflake-style layouts, but it is easy to exhaust if you try to reserve large shard and worker ranges at the same time.
Shard
Worker range
Packed start
Packed end
Binary shard prefix
Shard 0
0-31
0
31
0000 0
Shard 1
0-31
32
63
0000 1
Shard 2
0-31
64
95
0001 0
Shard 3
0-31
96
127
0001 1
Shard 4
0-31
128
159
0010 0
Shard 5
0-31
160
191
0010 1
Shard 31
0-31
992
1023
1111 1
JavaScript packing snippet
const shardBits = 5;
const workerBits = 5;
const workerMask = 31;
function packLane(shardId, workerId) {
return (shardId << workerBits) | workerId;
}
function unpackLane(value) {
return {
shardId: value >>> workerBits,
workerId: value & workerMask,
};
}
SQL decode snippet
SELECT
packed_lane_id >> 5 AS shard_id,
packed_lane_id & 31 AS worker_id;
Worker ID / shard ID generator for Snowflake-style bit splits, packed lane values, and
A worker ID / shard ID generator helps when you need to plan the low-bit lane pool behind a Snowflake-style identifier system. This page also explains the main assumptions behind the worker id / shard id generator for snowflake-style bit splits, packed lane values, and result, highlights the supporting figures shown by the calculator, and helps the reader use the estimate without overstating what a quick online tool can prove.
Why this page is separate from the Snowflake generator
A Snowflake generator answers one class of question: generate or decode the final 64-bit identifier. That is not the same job as lane planning. Teams often need to settle the worker and shard allocation scheme before they ever emit one production ID. That planning step decides how many shard groups you can run, how many workers fit inside each shard, and what packed low-bit values are legal.
That is why this page exists as a distinct calculator. It owns allocator intent, not final ID generation intent. If you need complete Snowflake IDs with timestamps and lower-bound query anchors, use the Snowflake page. If you need to size the worker and shard space that sits inside the low bits, this is the correct tool.
How worker and shard bits fit into a Snowflake-style layout
Snowflake-style systems keep a time field in the high bits and reserve a smaller low-bit pool for the generator lane and sequence. In many designs, that lane pool is further split into a shard-like grouping and a worker-like grouping. Twitter's classic arrangement is often described as 5 bits plus 5 bits inside a 10-bit lane pool, while Sonyflake exposes a larger 16-bit machine field that some teams subdivide internally.
That split is operationally important because every bit moved from one side to the other doubles one capacity dimension and halves the other. Giving one extra bit to shards doubles the shard count but cuts the worker count per shard in half. Giving one extra bit to workers does the opposite.
max shards = 2^(shard bits)
Shard capacity is determined only by how many low bits you reserve for shard grouping.
max workers per shard = 2^(worker bits)
Worker capacity inside each shard is determined by the remaining low bits after the shard split.
packed lane value = (shard id << worker bits) + worker id
One packed lane integer can carry both shard and worker identity when the split is known.
What allocator planning needs to solve
A good worker ID or shard ID planner should do more than echo powers of two. It should let you choose a bit split directly, size the split from required shard and worker counts, reserve IDs for future growth or special lanes, pack example values, and decode packed integers back into shard and worker parts.
That matters because real teams rarely use every theoretical slot on day one. They keep room for future regions, staging environments, migration buffers, or replacement workers. A planner that only states the raw maximums is not enough when the real question is whether the operational envelope still fits after those reservations.
Why packed lane values are useful
Some systems keep shard ID and worker ID as two explicit config values. Others pack both into one lane integer that is later shifted into the low bits of the final identifier. Packed lane values are useful because they make environment variables, deployment configs, and database metadata simpler: one number can still be reversed back into shard and worker parts when the split is known.
This also makes audits easier. If a worker lane is encoded as one integer, you can decode it with a simple bit mask and shift operation to confirm that a deployment is still pointing at the intended shard group and worker slot.
Why 5/5 is common but not universally correct
A 5-bit shard group plus 5-bit worker group is familiar because it gives 32 shards with 32 workers each inside a 10-bit lane pool. That is balanced and easy to reason about. But balance is not always the right answer. Some systems need many more worker lanes per shard than shard groups. Others need only a handful of workers but many tenant or region buckets.
That is exactly where a dedicated shard ID calculator helps. It makes the trade-off explicit instead of letting teams carry forward a hand-me-down split that was correct for somebody else's topology.
Sonyflake and larger machine pools
Sonyflake is useful here because it exposes a larger 16-bit machine field than classic 10-bit Snowflake worker space. Some teams keep that field flat as one machine identifier. Others subdivide it into rack, shard, region, or worker segments for their own control plane. Once you do that, you are back in the same allocator problem: each extra shard bit takes one worker bit away.
This page therefore treats Sonyflake as a planning preset rather than as proof that there is one universal split. The bigger machine pool simply gives you more room to make the trade-offs deliberately.
Worked example: deciding whether a 10-bit pool is enough
Suppose you expect 20 shards and about 20 workers in each shard. At first glance, a classic 10-bit pool might seem fine because 20 and 20 both sound smaller than 32. The problem appears when you add reservation space. If you keep a couple of shard IDs in reserve and leave spare worker slots for blue-green replacement or future scale, the fit can become much tighter than it first looked.
This planner makes that visible immediately. In capacity mode, you can enter the requested shard count, worker count, and reserved IDs, then see the minimum shard bits needed and whether the remaining worker side still fits. That prevents the common mistake of approving a split using only headline powers of two and no operational buffer.
Where this page beats thin public alternatives
Most public Snowflake tools focus on generating full IDs or decoding timestamps. That is useful, but it leaves a gap for teams still deciding the worker and shard allocation itself. This page fills that gap with split planning, capacity sizing, packed value generation, packed value decoding, assignment previews, and copyable bit-shift snippets.
That is what makes it best in class for this narrower intent. Instead of forcing users to mentally translate a full Snowflake decoder into an allocator worksheet, the page gives them the allocator worksheet directly.
Frequently asked questions
What is a worker ID in a Snowflake-style system?
A worker ID identifies one generator lane inside the low-bit pool of a Snowflake-style identifier. It is there to keep simultaneous generators from colliding when they emit IDs in the same time slice.
What is a shard ID in this planner?
Here, shard ID means the higher-order part of a packed worker/shard lane pool. Teams may call it shard, datacenter, region, rack, or group ID depending on the deployment model. The math is the same once you choose how many bits it receives.
How do I calculate how many shards fit in a bit split?
Take two to the power of the shard bits. For example, 5 shard bits give 32 shard values, 6 bits give 64, and 8 bits give 256.
How do I calculate how many workers fit per shard?
Take two to the power of the worker bits that remain after the shard split. For example, 5 worker bits give 32 workers per shard, while 10 worker bits give 1,024 workers per shard.
What is a packed lane value?
A packed lane value is one integer that combines shard ID and worker ID. It is commonly built by shifting the shard ID left by the worker-bit count and then adding or OR-ing the worker ID.
Is 5 shard bits and 5 worker bits always the best split?
No. It is common because it is balanced inside a 10-bit pool, but the right split depends on your real shard count, worker count, and reserved growth space.
Why would I reserve shard IDs or worker IDs?
Teams often reserve IDs for future growth, blue-green swaps, regional expansion, migration lanes, or operational conventions. Planning without those reserves can make a design look safer than it really is.
Can I use this planner for Sonyflake machine bits?
Yes. Sonyflake exposes a 16-bit machine field, and this planner can model how that field behaves if you subdivide it into shard-like and worker-like segments for internal allocation.
Does this page generate full Snowflake IDs?
No. This page plans and packs the worker/shard lane portion only. Use the Snowflake ID Generator page when you need the full time-ordered ID with timestamp and sequence fields.
