ANSI functions are not inherently slower — the query planner optimizes both equally. The real performance considerations are:

1. **Index utilization**: Vendor-specific functions sometimes prevent index use (e.g., wrapping a column in CAST). ANSI CAST has the same risk — test with EXPLAIN.

2. **Pagination performance**: LIMIT/OFFSET and FETCH FIRST have identical performance. The real issue is deep pagination (OFFSET 10000 scans 10,000 rows regardless of syntax).

3. **MERGE vs ON CONFLICT**: MERGE is heavier (row-level locking, complex parsing). PostgreSQL's ON CONFLICT is lighter for high-throughput upserts.

4. **CONCAT vs ||**: Identical performance. CONCAT is slightly more defensive — it returns NULL if any arg is NULL in SQL Server, but NULL-coerces in PostgreSQL. Know your database's NULL behavior.

Rule of thumb: Use ANSI SQL for portability unless profiling shows a specific vendor function is 2x+ faster for your workload.

ANSI functions and their vendor equivalents have identical query plan performance — the optimizer treats them the same

Deep pagination (OFFSET 10000+) is slow on every database regardless of LIMIT vs FETCH FIRST — use keyset pagination

Correlated subquery workarounds for MySQL 5.7 (replacing window functions) can be 5–20x slower

PostgreSQL ON CONFLICT is lighter-weight than MERGE for high-throughput upserts

CASE WHEN for conditional aggregation performs identically to the FILTER clause

Using || for string concatenation in MySQL — it returns 0 (logical OR result) not the concatenated string

Copying PostgreSQL FETCH FIRST to SQL Server — SQL Server requires FETCH NEXT

Using REPLACE INTO when you want upsert — it deletes and reinserts, cascading to child tables

Forgetting that MySQL 5.7 has zero window function support

Using WHERE column = NULL instead of WHERE column IS NULL

Using TRUE/FALSE literals in SQL Server — BIT type only accepts 1/0