Eager Loading with Column Constraints vs Lazy Loading for Lumen Eloquent Relationships in High-Volume APIs

Goal: Determine whether to use eager loading with selected columns or lazy loading for a Lumen Eloquent relationship in an API endpoint that returns a collection of parent models, aiming to minimize latency while keeping memory consumption within acceptable limits.

Constraints: The endpoint may return anywhere from a few to several hundred parent records per request, and the related table can contain multiple columns, some of which are large (e.g., TEXT or BLOB). Eager loading reduces the number of SQL queries but can load unnecessary data, increasing memory footprint; lazy loading keeps the initial query lightweight but may trigger many additional queries under load, potentially causing latency spikes.

Uncertainty: It is unclear at what approximate number of parent records the memory overhead of eager loading, even when columns are constrained, begins to outweigh the benefit of reduced query count, and how this breakpoint shifts with different payload sizes and concurrent request volumes.

Specific questions:

• At roughly how many parent records does eager loading with constrained columns start to increase peak memory usage beyond a typical PHP‑FPM limit for a given average relationship size?
• How does the latency difference between the two strategies change when the relationship table includes large columns that are not selected in the eager load constraint?
• Under what concurrent request conditions does the N+1 query penalty of lazy loading become more detrimental than the memory penalty of eager loading?