Doctrine Snowflake Id Bundle Laravel Package

Product Decisions This Supports

• Primary key / ID strategy selection for new services. This package implements Snowflake-style 64-bit, time-sortable identifiers as a Doctrine integration (attribute + listener + autowiring). It directly informs the "auto-increment vs. UUIDv4 vs. UUIDv7 vs. Snowflake" decision for any new Symfony service backed by Doctrine.
• Build vs. buy on ID generation. Snowflake generation is roughly 100–200 lines of code; the differentiated value here is the Doctrine plumbing (entity attribute, event listener, configuration autowiring, and now ODM/MongoDB support). The PM decision is whether that glue is worth an external dependency versus an internal IdGenerator service — this package is small enough to vendor or fork if needed.
• Database portability and MongoDB adoption. The v1.0.0 release adds Doctrine ODM MongoDB compatibility, which unlocks a decision to use one ID scheme across a relational store (ORM) and a document store (ODM) in the same product. That matters if you are splitting read models, audit logs, or event stores into MongoDB.
• Sharding, partitioning, and time-ordered indexing. Sortable IDs reduce index fragmentation and enable range-based archival/retention. Relevant to roadmap items around multi-tenant partitioning, data warehouse exports, and hot/cold storage tiering.
• External-facing identifier exposure. Snowflake IDs avoid leaking sequential record counts while remaining URL-safe and sortable — a factor in API design and privacy/security review decisions.
• Scope correction for planning purposes: the package is a Symfony/Doctrine bundle, not a Laravel package. It should not be planned into a Laravel codebase. For Laravel, the equivalent decision requires a different dependency (e.g., a Laravel-specific Snowflake package) or an internal generator; this bundle's main transferable insight is the ID-strategy tradeoff, not the code.

When to Consider This Package

Consider adoption when:

• The service is Symfony-based and uses Doctrine ORM and/or Doctrine MongoDB ODM.
• You need IDs that are unique across multiple application nodes without a central sequence, and that sort chronologically for efficient B-tree indexes and range queries.
• You are standardizing one ID format across relational and document stores.
• You need IDs generated at the ORM/ODM layer automatically (attribute-driven), with configuration managed through the container rather than manual generator calls in every entity.
• You accept a young, single-maintainer dependency and can pin versions and wrap it behind an internal abstraction.

Look elsewhere when:

• Laravel or any non-Symfony framework — no service provider, no Laravel integration; this package will not autowire or register in a Laravel app.
• Your database or platform already provides a strong answer: PostgreSQL sequences with bigint, ULIDs, or native UUIDv7 (now available in several databases and libraries) may cover the need with zero new dependencies.
• You require vendor-backed SLAs, long support windows, or a security review process that a pre-1.x-history, single-contributor project cannot satisfy.
• You need coordinated worker-ID assignment across a fleet (datacenter/worker bits must be unique or you risk collisions); this package will not solve that governance problem for you.
• You need monotonicity guarantees under clock skew — Snowflake IDs are clock-dependent and require NTP discipline and drift handling, which you must validate yourself in v1.0.0.
• You are on a stack where IDs are generated outside the persistence layer (e.g., domain-layer factory, API gateway) and an ORM listener is the wrong seam.

Adoption guardrails if you proceed: pin the exact version, run it in a non-critical service first, write a collision/clock-skew test, and keep an internal interface in front of it so a swap is a one-file change.

How to Pitch It (Stakeholders)

For executives (one paragraph): A small open-source library that generates sortable, globally unique record IDs for our Symfony services, and now also for MongoDB. It is a low-cost, low-risk, easily reversible infrastructure choice — not a platform commitment. The strategic upside is better database performance at scale and one consistent ID scheme across our relational and document stores. The caveats are maturity and support: this is a v1.0.0 from a single maintainer, so we should adopt it behind an internal abstraction and pilot it on one service rather than standardize on it immediately.

For engineering leads: This is a thin Doctrine integration — an attribute, an event listener, and container autowiring around a Snowflake generator — plus new ODM/MongoDB support and the project's first real test coverage for the listener. It removes boilerplate rather than adding a framework. Risks are the usual for a young dependency: clock-skew correctness, worker-ID coordination across nodes, and API stability before 1.x has seen wide use. Effort to adopt is hours, not sprints; effort to remove is similarly small if we isolate it.

Recommended next step: Timebox a one-service evaluation. Verify ID uniqueness and ordering under concurrent load, confirm MongoDB path if that is on the roadmap, and decide within one sprint whether to standardize or fall back to database-native sequences or UUIDv7.