Model Manager Laravel Package

Product Decisions This Supports

• Framework-fit triage (build vs. buy). This is a Pomm component, not a Laravel package. Pomm is a PostgreSQL-only, SQL-first object mapper with its own connection layer; there is no Eloquent, no service provider, no migrations, no factories, no artisan generators. Any decision framed as "drop this into our Laravel app" should be closed as do not adopt unless the service is being built Postgres-first and outside Eloquent.
• Data-access architecture for Postgres-heavy services. Where the roadmap includes complex schemas, read models, reporting tables, or hand-tuned SQL that Eloquent expresses poorly, a thin row-to-object mapper is a legitimate alternative to an ORM. This package is one implementation to benchmark, not a default.
• Schema-introspection and admin tooling. If the roadmap includes internal admin panels, schema browsers, or code generation from an existing database, a model manager that derives model shape from the catalog is directly on-path. This is the strongest genuine use case.
• Legacy Postgres estate integration. For products that must talk to an existing database they do not own (no migrations, no schema changes allowed), an introspection-driven mapper avoids hand-writing dozens of DTOs.
• Dependency risk register entry. 0 stars, 0 dependents, score 0, opportunity 33.1. That is a signal of no community validation and no downstream production usage that you can observe. Any roadmap item depending on it must carry an explicit "we own this code" line item rather than an implicit "the maintainer will fix it" assumption.
• Not supported: choosing this as the team's ORM standard, as a Doctrine/Eloquent replacement for a multi-database product, or as a dependency in a client-facing SLA path.

When to Consider This Package

Consider it only when all of the following hold:

• The datastore is PostgreSQL and will remain PostgreSQL. Pomm leans on Postgres-specific behavior; portability is not a goal.
• The team has existing Pomm fluency, or is deliberately choosing a SQL-first data layer over an ORM.
• The work is read-heavy mapping, introspection, or generated models — not rich domain modeling with relations, eager loading, casting, events, and lifecycle hooks.
• The service is decoupled from Laravel's Eloquent conventions (separate connection, explicit SQL, no Model::query() expectations from the rest of the team).
• You have completed a maintenance audit: last commit date, open issue count, PHP version support, whether this is a fork tracking upstream Pomm, and whether ext-pgsql/PDO requirements match your runtime and deployment image.

Look elsewhere when:

• You need MySQL, MariaDB, SQLite, or SQL Server support → Doctrine DBAL, Laravel's query builder, or Eloquent.
• You need relations, eager loading, migrations, model events, casting, or soft deletes → Eloquent (Laravel-native) or Doctrine ORM (framework-agnostic).
• You only need typed hydration from query results into DTOs → CuyZ/Valinor or jms/serializer; these are actively maintained and database-agnostic.
• You need a maintained abstraction over raw SQL with no mapping layer → Doctrine DBAL.
• You need long-term vendor support, security patching, or an upgrade path you can cite in a compliance review → a package with zero dependents is a poor answer.

Adoption guardrails if you proceed anyway: MIT license permits vendoring the source into your repo, which you should do; pin a commit SHA; add your own characterization tests around the mapper; and assign a named owner for the fork.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed PHP component for mapping PostgreSQL rows to objects, built for a niche framework called Pomm. It is not a Laravel package and does not integrate with our existing stack. Its community footprint is effectively zero — no stars, no dependent projects — so it carries no external support guarantee. My recommendation is a time-boxed two-day technical spike at near-zero cost, not a commitment. Treat any outcome as "we forked and now own ~a few hundred lines," which is a favorable trade against hand-writing mapping code only if the Postgres-first assumption holds.

To engineering: The value proposition is narrow and real: it removes boilerplate when you are working against a schema you did not design, and it keeps SQL visible instead of hiding it behind an ORM. The cost is equally real: no Eloquent integration, a separate connection layer, Postgres-only, an unvalidated maintenance story, and a hard dependency on pgsql being present in every environment. We should benchmark it against two baselines we already have — Eloquent with raw select clauses, and Doctrine DBAL with hand-rolled hydration — and pick on measured lines-of-code and query transparency, not on novelty.

The ask: approve the spike, and pre-approve the fork-and-own pattern if the spike wins. Do not put this on a roadmap as a strategic platform choice.