[RFC] Cross-Database Consistency for Eloquent's first() Method

[NacerKH]

The Problem

PostgreSQL's first() returns different results than MySQL/MariaDB due to MVCC and query planner behavior:

User::first(); // MySQL: Always User ID 1
User::first(); // PostgreSQL: Changes when rows are updated

Real Impact:

• Feature flags return different defaults across environments
• Admin dashboards show inconsistent "first" records
• Tests pass in MySQL, fail in PostgreSQL
• Production surprises when switching databases

Root Cause: PostgreSQL MVCC

When you update a row in PostgreSQL:

$user = User::find(5);
$user->save(); // Creates new row version

User::first(); // Now returns different user!

PostgreSQL creates new row versions on updates, changing physical storage order and affecting LIMIT without ORDER BY.

Proposed Solution

Add conservative auto-ordering to first():

// Only when ALL conditions met:
// ✅ Simple Model::first() 
// ✅ No existing ORDER BY
// ✅ No joins or WHERE clauses
// ✅ Model has primary key

User::first(); // Auto-adds ORDER BY id

// These stay unchanged:
User::where('active', true)->first(); 
User::orderBy('name')->first();
User::join('posts')->first();

Performance: ~0.1-0.5ms overhead, uses existing primary key index.

Alternative Approaches

1. New method: User::firstOrdered()
2. Config flag: 'consistent_first' => true
3. Better docs: Just explain the differences
4. Do nothing: Keep current behavior

Questions for You

Have you experienced this PostgreSQL inconsistency?

• Yes, caused production issues
• Yes, caught in development/testing
• Suspected but never confirmed
• Never encountered

What's your preference?

• Fix first() with conservative auto-ordering
• Add new firstOrdered() method instead
• Make it configurable per connection
• Keep current behavior, improve docs
• Other idea: _______________

Concerns about changing first() behavior?

• Breaking changes for existing apps
• Performance impact
• Too much "magic"
• Should be explicit, not implicit
• No concerns

Which databases do you use in production?

• MySQL only
• PostgreSQL only
• Both MySQL and PostgreSQL
• Other: _______________

Your Experience Matters

This affects every Laravel app using PostgreSQL. Whether you're running multi-database setups, migrating between engines, or just want predictable behavior - your input shapes this decision.

Drop your thoughts below - especially real-world examples of this causing issues or why you think the current behavior should stay!

[macropay-solutions]

We had to change mysql behavior for count when we migrated to mysql 8 due to MVCC to avoid db clogging on millions rows tables and we did it outside the framework via macros. That to would qualify as a RFC if your RFC would get into the framework.

Changing this in eloquent just for one of the many supported db types might introduce issues.

We would introduce a default sort by pk in a custom eloquent builder if the table has an auto-incrementing/ ordered UUID pk etc.

// Only when ALL conditions met:
// ✅ Simple Model::first()
// ✅ No existing ORDER BY
// ✅ No joins or WHERE clauses
// ✅ Model has primary key

by overwriting the first method.

[macropay-solutions]

@NacerKH What if you want to get first row not first row by pk?

[NacerKH]

@macropay-solutions You raise a good point. Maybe instead of changing first(), we need better alternatives:

Keep first() as-is but add documentation warnings
Introduce firstOrdered() that guarantees PK ordering
Add firstDeterministic() for when you need predictable results
Or safeFirst() that throws an exception without explicit ordering

This way developers can choose based on their needs without breaking existing code.

[macropay-solutions]

@NacerKH macro + documentation warnings would be our choice.