Instagram Snowflake Generator

Instagram IDs: a Snowflake fork for sharded Postgres

Instagram migrated from auto-incrementing Postgres primary keys to a Snowflake-style 64-bit ID in 2012, after the company sharded its database fleet. Mike Krieger's engineering blog post that year is still the canonical reference — it describes how the team needed IDs that were globally unique, time-sortable, fit in a SQL BIGINT, and — critically — encoded the logical shard so the ID could be routed back to its own Postgres node without a lookup table.

Bit layout used by Instagram

 41 bits        | 13 bits     | 10 bits
 timestamp ms   | shard id    | per-shard sequence
 since 2011-08  | (0-8191)    | (0-1023)

The Instagram epoch is 1314220021721 (August 24, 2011). To decode a media ID back to its creation time: unix_ms = (snowflake >> 22) + 1314220021721. Thirteen shard bits allow 8,192 logical shards — Instagram pre-allocated more shards than physical machines so they could rebalance later. The 10-bit sequence allows 1,024 IDs per millisecond per shard, which matches the throughput of a single Postgres node comfortably.

Shortcodes, Reels, Stories, Threads

• URL shortcode — what you see in instagram.com/p/<shortcode> is a base64-style encoding of the BIGINT ID. Community converters round-trip shortcode ↔ ID ↔ timestamp.
• Story / Reel media IDs — same 64-bit shape, different internal sub-bit allocation depending on the surface.
• Threads (Meta, 2023) — runs on the same Instagram backend, so post IDs follow the same Snowflake-style structure.
• Comparison — Twitter Snowflake = 41 ts + 5 datacenter + 5 worker + 12 sequence. Discord = 42 ts + 5 dc + 5 worker + 12 sequence with epoch 1420070400000. Instagram swaps datacenter/worker for the logical shard ID.

Why generate mock Instagram IDs?

Realistic-shaped IDs are useful for seeding test databases, mocking Graph API responses, validating schema migrations, building demo dashboards, and stress-testing scrape-detection logic. Meta has never officially documented the exact bit layout — the structure above was reverse-engineered by the community and confirmed empirically by decoding millions of public post IDs.

Privacy and forensic angle

Because the ID embeds the creation timestamp, every Instagram post leaks the exact millisecond it was created — useful for OSINT and forensics, problematic for privacy. Account creation dates and posting cadence become trivially extractable from any public profile, which is one reason Meta nudges integrations toward the Graph API instead of HTML scraping.

FAQ

Can I extract the creation date from a real Instagram post ID? Yes — right-shift the ID by 22 bits and add the Instagram epoch 1314220021721. The result is the Unix millisecond when the post was created.

Is scraping Instagram IDs legal? Meta's Terms of Service prohibit unauthorised scraping. For production integrations, use the official Instagram Graph API endpoints. The IDs themselves are public, but how you obtain them matters.

Do the mock IDs collide with real ones? Statistically possible but extremely unlikely. The IDs are valid in shape, not registered with Meta — they exist only inside your test database.

How does this differ from Twitter Snowflake? Twitter uses 5 bits for datacenter and 5 for worker (10 bits of machine identity). Instagram replaces those 10 bits with 13 bits of logical shard ID and reduces the sequence to 10 bits — trading throughput for finer shard granularity.