DEV Community: Szj

The State of Mutation Testing (Infection) in the PHP Ecosystem: A Scientific and Practical Analysis

Szj — Sun, 11 Oct 2026 05:33:02 +0000

Abstract

For decades, Code Coverage has served as the primary quality assurance metric in the software engineering industry. However, this metric often provides a false sense of security: it merely proves that a specific line of code was executed during a test run, but it does not guarantee that the test contains relevant and rigorous assertions. Mutation Testing provides an exact solution to this anomaly, with the Infection framework becoming the de facto standard in the PHP ecosystem. This analysis examines the efficacy, exponential resource requirements, theoretical limitations, CI/CD applicability, and the Return on Investment (ROI) of the methodology in enterprise environments.

1. Theoretical Background and Methodology

The fundamental question of mutation testing—and a core paradox of quality assurance—is: "Who guards the guards?" In other words, what mechanism can validate the reliability of the test suite itself?

The Infection PHP framework operates through the dynamic manipulation of the Abstract Syntax Tree (AST). During execution, the program injects syntactically correct but semantically incorrect modifications (mutations) into the source code.

Typical mutation operators include:

Arithmetic mutations: Replacing the + operator with the - operator.
Relational mutations: Degrading a > (strictly greater than) condition to a >= (greater than or equal to) condition.
Return value and boolean mutations: Replacing return true with return false, or removing method calls entirely.

Each autonomously generated, modified version of the code is called a Mutant. Following generation, the system iteratively runs the existing test suite against the given mutant:

If the test fails, the mutant is considered Killed. This is the ideal scenario, proving that the test suite is sufficiently defensive.
If the test passes successfully, the mutant has Escaped the assertions. This clearly indicates that the test suite is blind to that specific change in the business logic.

From these results, the framework aggregates the MSI (Mutation Score Indicator), which represents the percentage of successfully killed mutants.

2. The Value Proposition (ROI)

Based on scientific research and industry experience, the integration of Infection results in a significant paradigm shift regarding software quality.

Empirical Measurement of Software Quality: A traditional 100% Line Coverage can be achieved even if the tests contain absolutely no assert statements. In contrast, the MSI metric cannot be manipulated. Mutation testing ruthlessly exposes unhandled edge cases, the over-preference for the "happy path," and the lack of robustness in the code.
Identification of Redundancy and "Dead Code": The methodology identifies overly complex control flows with surgical precision. If a mutant continuously survives tests within a complex branch, it most often indicates that the specific code block is unreachable based on business logic (dead code), or it is so redundant that it requires immediate refactoring.
Cultural and Developer Education: The methodology proactively shapes the test-writing culture of engineering teams. Engineers learn to write higher-quality, defensive code and more rigorous assertions, minimizing the ratio of superficial tests.

3. Technological Limitations and Critical Analysis

While the methodology is theoretically sound, its practical implementation—especially in large-scale enterprise environments—faces severe technological and resource constraints.

3.1. Combinatorial Explosion and Computational Overhead

The most significant obstacle to mutation testing is its exponential resource requirement. If a project has 1,000 tests and Infection generates 5,000 mutants, it theoretically requires the test suite to be executed 5,000 times.

The continuous rebuilding of the AST and the thousands of initializations of the test runner (PHPUnit/Pest) introduce extreme CPU and memory loads. A standard 2-minute Continuous Integration (CI) test run can easily balloon to 40-60 minutes with full-scale Infection application, which is incompatible with the fast feedback loops expected in modern Agile/DevOps pipelines.

3.2. The Equivalent Mutants Problem

Academic studies unanimously refer to the phenomenon of equivalent mutants as the deepest, still only partially solved challenge of mutation testing. These are syntactic transformations that do not mathematically or logically alter the final semantics of the code.

Example: An operator change made for optimization purposes in a loop's indexing creates a mutation, but the algorithm's output remains invariant.

Because these mutants naturally always survive the tests, they falsely degrade the MSI score. Developers can lose valuable work hours manually analyzing these false positives, leading to what is known as "Developer Fatigue."

3.3. Implementation Challenges in Legacy Systems

Introducing Infection into a monolithic PHP application with high technical debt and low (sub-50%) test coverage is counterproductive. The system will generate surviving mutants in the tens of thousands, creating unprocessable informational noise for the team. The methodology only provides true value in codebases that already possess dedicated, high coverage (ideally above 85%).

4. Modern Optimization Strategies (CI/CD Integration)

To ensure sustainable usage, the PHP community and framework maintainers have introduced innovative architectural solutions that allow mutation testing to be integrated into daily development cycles:

Multithreading: Modern PHP environments (e.g., via the pcntl extension) support the asynchronous, parallel processing of mutants. Fully utilizing available CPU cores (e.g., --threads=4) drastically reduces execution time.
Incremental Diff-Based Testing: This represents the greatest technological breakthrough. In modern CI pipelines, Infection does not scan the entire codebase; instead, it strictly limits mutant generation to the lines of code modified in the Pull Request or Git commit (--git-diff-lines). This technique reduces runtime from hours to mere seconds.
Baseline Architecture: Similar to static code analyzers (PHPStan, Psalm), Infection can save existing, historical surviving mutants into a reference file (baseline). Consequently, the CI process only fails if a developer attempts to integrate new, inadequately tested code into the system.

5. Conclusion and Architectural Recommendations

The application of mutation testing is not a universal silver bullet; its adoption requires a deliberate engineering decision.

Critically Recommended Application Areas:

Financial technologies (FinTech), payment gateways, and transactional systems.
High-risk healthcare and government software.
Widely used Open Source libraries (e.g., the Symfony and Doctrine ecosystems actively benefit from this level of scrutiny).
Isolated testing of the Core/Domain (business) layer in software built on strict Domain-Driven Design (DDD) principles.

Contraindicated Areas:

Rapid prototypes and applications in the MVP (Minimum Viable Product) phase.
Simple CRUD (Create, Read, Update, Delete) and administrative interfaces.
Thin API endpoints where the code exclusively performs database reads without complex logical transformations.

Final Verdict: The application of Infection in the PHP ecosystem represents the current State of the Art in software quality. Engineering teams willing to navigate the adoption curve and manage the increased CI/CD resource requirements will achieve a degree of mathematical and logical stability that is completely unattainable with traditional coverage metrics.

Bibliography and References

[1] DeMillo, R. A., Lipton, R. J., & Sayward, F. G. (1978). Hints on Test Data Selection: Help for the Practicing Programmer. IEEE Computer, 11(4), 34-41. (The foundational work laying the theoretical groundwork for mutation testing).
[2] Jia, Y., & Harman, M. (2010). An Analysis and Survey of the Development of Mutation Testing. IEEE Transactions on Software Engineering, 37(5), 649-678. (A comprehensive industry study on the adoption and efficacy of mutation testing).
[3] Offutt, A. J., & Pan, J. (1996). Detecting Equivalent Mutants and the Feasible Path Problem. Proceedings of the 11th Annual Conference on Computer Assurance (COMPASS '96). (Scientific analysis of the equivalent mutants phenomenon and the challenges of detecting them discussed in this article).
[4] Infection PHP Official Documentation. (2024). Infection - PHP Mutation Testing Framework. Available at: infection.github.io (Official reference for technical implementation details, Git Diff filtering, and Baseline functionality).

5 Angular Anti-Patterns You Need to Stop Using Immediately (and How to Fix Them in Angular 21)

Szj — Sun, 11 Oct 2026 04:58:00 +0000

Angular is a robust, enterprise-grade framework, but with great power comes great responsibility. Because Angular gives us so much freedom, it is incredibly easy to shoot ourselves in the foot, especially as the application starts to scale.

If your app feels sluggish, or if your components are becoming an unmaintainable mess, chances are you are falling victim to a few common bad habits.

Let's look at 5 of the most frequent Angular anti-patterns and how to refactor them using modern, clean code practices tailored for Angular 21.

1. Function Calls in Templates (The Performance Killer)

The Anti-pattern: Calling a component method directly in your HTML template for data binding.

<!-- [BAD]: This will execute on every single Change Detection cycle -->
<p>Total: {{ calculateTotal(cartItems) }}</p>
<div [class.active]="checkIfUserIsActive(user)"></div>

Why it is bad: Angular's Change Detection (CD) is aggressive by default. Every time anything happens (a click, a timer, an HTTP response), Angular checks the template for changes. If you bind a function in the template, Angular has to re-execute that function every single CD cycle to see if the return value changed. If calculateTotal involves heavy array manipulation, your app will freeze.

The Modern Solution:
Use Pure Pipes for transformations, or better yet, use Angular 21 Signals.

// [GOOD]: Using Angular 21 Signals
cartItems = signal<CartItem[]>([]);

// computed() caches the value and ONLY recalculates if cartItems changes!
total = computed(() => this.cartItems().reduce((acc, item) => acc + item.price, 0));

<!-- [GOOD]: Just binding to the computed signal -->
<p>Total: {{ total() }}</p>

2. Abandoned Subscriptions (The Memory Leak)

The Anti-pattern: Subscribing to an Observable but forgetting to unsubscribe when the component is destroyed.

// [BAD]: This subscription lives forever, even if the user navigates away.
ngOnInit() {
  this.userService.getUserData().subscribe(data => {
    this.userData = data;
  });
}

Why it is bad: When the Angular Router destroys this component, the subscription remains active in memory. This leads to memory leaks and ghost code executions in the background, causing weird UI bugs and crashing browsers.

The Modern Solution:
If you must use RxJS instead of Signals for a specific data stream, use the takeUntilDestroyed() operator. In modern Angular, you do not even need to implement ngOnDestroy for this.

// [GOOD]: Modern approach
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';

export class UserComponent {
  constructor(private userService: UserService) {
    this.userService.getUserData()
      .pipe(takeUntilDestroyed()) // Automatically unsubscribes on destroy!
      .subscribe(data => this.userData = data);
  }
}

3. Nested Subscriptions (The Reactive "Callback Hell")

The Anti-pattern: Subscribing to an Observable inside another Observable's subscribe block.

// [BAD]: Hard to read, impossible to test, and prone to race conditions.
this.route.params.subscribe(params => {
  this.userService.getUser(params['id']).subscribe(user => {
    this.projectService.getProjects(user.organizationId).subscribe(projects => {
      this.projects = projects;
    });
  });
});

Why it is bad: It breaks the declarative nature of RxJS. More importantly, it creates race conditions. If the user clicks fast and triggers multiple ID changes, the HTTP responses might arrive out of order, rendering the wrong data on the screen.

The Modern Solution:
Leverage Higher-Order Mapping operators like switchMap, concatMap, or mergeMap.

// [GOOD]: Clean, linear, and handles race conditions safely.
this.projects$ = this.route.params.pipe(
  switchMap(params => this.userService.getUser(params['id'])),
  switchMap(user => this.projectService.getProjects(user.organizationId))
);

(Note: switchMap is perfect here because it cancels previous pending requests if a new ID is emitted).

4. "Fat" Components (The God Object)

The Anti-pattern: Stuffing business logic, direct HTTP calls, and complex state manipulation directly into the .ts file of your component.

Why it is bad: Your component becomes a monolith. It becomes untestable (because you have to mock 15 different dependencies) and impossible to reuse. UI components should only care about presenting data and catching user events.

The Modern Solution:
Adopt the Smart / Dumb (Presentational) Component Architecture using Standalone Components, and use a Facade or Service for logic.

Move your HTTP logic and state mutations into a dedicated Service, keeping your component clean:

// [GOOD]: The component just binds to the facade service.
@Component({
  standalone: true,
  // ...
})
export class CartComponent {
  // Injecting the service using the modern inject() function
  private cartFacade = inject(CartFacadeService);

  cartItems = this.cartFacade.items; // This is a Signal exposed by the service

  onRemoveItem(id: string) {
    this.cartFacade.removeItem(id); // The service handles the actual logic and API call
  }
}

5. The Desperate `ChangeDetectorRef` Hack

The Anti-pattern: Injecting ChangeDetectorRef and throwing cdr.detectChanges() or wrapping code in setTimeout(() => {}, 0) just to force the UI to update.

// [BAD]: Forcing Angular to update because the data flow is broken.
updateUser() {
  this.user.name = 'John';
  this.cdr.detectChanges(); // Please update the UI, I am begging you!
}

Why it is bad: If you find yourself using this, it means you have lost control of your state management or you are mutating data directly instead of creating new references. It is treating the symptom instead of curing the disease.

The Modern Solution:
Embrace Zoneless Angular and Immutability.

Angular 21 fully supports going Zoneless (provideZonelessChangeDetection()). In a Zoneless environment, the framework relies entirely on Signals and built-in reactive primitives to know when to update the DOM, eliminating the need for Zone.js overhead or manual cdr.detectChanges() hacks.

// [GOOD]: Treat data as immutable and use Signals for automatic UI updates
@Component({
  standalone: true,
  // ChangeDetectionStrategy.OnPush is also recommended if you are not fully zoneless yet
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class UserComponent {
  user = signal({ name: 'Jane', age: 30 });

  updateUser() {
    // Updating the signal automatically schedules a highly optimized UI update
    this.user.update(u => ({ ...u, name: 'John' })); 
  }
}

Wrapping Up

Angular has heavily shifted towards a reactive, Signal-driven, and Zoneless future. By dropping these 5 anti-patterns and embracing the paradigms of Angular 21, you will immediately notice improvements in your app's Lighthouse scores, memory footprint, and overall developer experience.

Over to you: Which of these anti-patterns do you see most often in legacy codebases? Are there any others you would add to this list? Let me know in the comments!

PostgreSQL 19 WAIT FOR LSN from PHP: read-your-writes on a replica, and four ways it bites" published: false

Szj — Wed, 30 Sep 2026 18:26:12 +0000

You add a read replica. A user saves a form, gets redirected, and the next page shows the old data. The write went to the primary, the read went to the replica, and the replica hadn't caught up yet.

PostgreSQL 19 adds a built-in answer: the WAIT command. You give it the WAL position (LSN) of your write, and the replica blocks until it has replayed that far. I tried it from PHP on PostgreSQL 19 Beta 4, and found a few things worth knowing before you ship it.

Note: PostgreSQL 19 was at Beta 4 when I wrote this. Check the final release notes, as details may still change.

The problem, measured

Setup: one primary and one asynchronous streaming standby on the same machine, PHP 8.5.10 with PDO. After each INSERT on the primary I read the row back from the replica immediately.

5000 of 5000 reads were stale. Not most of them. All of them. The read arrives about 60 µs after the commit, and the row takes roughly 300 µs to get replayed on the replica. Under write load (pgbench with 4 clients on the primary) it was 1496 of 1500.

The fix

WAIT FOR LSN '0/0306EE20' WITH (TIMEOUT '50ms', NO_THROW);
-- returns one row: success | timeout | not in recovery

The flow: write on the primary, grab the current LSN, run WAIT on the replica, then read from the replica.

final class ReadYourWrites
{
    public function __construct(
        private PDO $primary,
        private PDO $replica,
        private int $timeoutMs = 50,
    ) {}

    /** Call right after the write has committed on the primary (synchronous_commit = on). */
    public function commitLsn(): string
    {
        return $this->primary->query('SELECT pg_current_wal_flush_lsn()')->fetchColumn();
    }

    /** Returns the connection that is safe to read from. Never call inside an open transaction. */
    public function readerFor(?string $lsn): PDO
    {
        if ($lsn === null) {
            return $this->replica;
        }
        if (!preg_match('~^[0-9A-F]+/[0-9A-F]+$~', $lsn)) {
            throw new InvalidArgumentException('Not a valid LSN');
        }
        $status = $this->replica
            ->query("WAIT FOR LSN '$lsn' WITH (TIMEOUT '{$this->timeoutMs}ms', NO_THROW)")
            ->fetchColumn();

        return $status === 'success' ? $this->replica : $this->primary;
    }
}

Result on 5000 writes: 0 stale reads, with a median wait of 315 µs on an idle standby and 1.2 ms under write load. If the replica can't catch up in time, the code falls back to the primary, which is always correct.

The LSN has to travel with the user between requests. Keep it in the session, and read from the replica only after WAIT succeeds.

Scenario	Stale reads without WAIT	Stale reads with WAIT	WAIT median
Idle standby	5000 / 5000	0 / 5000	315 µs
Write load	1496 / 1500	0 / 1500	1.2 ms

All numbers come from a single vCPU running everything (primary, standby, PHP, pgbench), so absolute latencies are inflated and a real network adds a round trip. Treat the ratios, not the microseconds, as the point.

Gotcha 1: you can't bind the LSN

WAIT is a utility command, so PostgreSQL doesn't accept parameters in it. With PDO's default native prepared statements:

$stmt = $replica->prepare('WAIT FOR LSN :lsn');
$stmt->execute(['lsn' => $lsn]);
// SQLSTATE[42601]: syntax error at or near "$1"

It only works with ATTR_EMULATE_PREPARES = true. The safe option is to validate the string with a strict regex (as in the class above) and interpolate it. An LSN is just hex, a slash and hex.

Gotcha 2: it must be the first thing in a transaction

The docs say WAIT can't run while you hold a snapshot or locks. In practice:

$replica->beginTransaction();
$replica->query('SELECT count(*) FROM t');
$replica->query("WAIT FOR LSN '$lsn'");
// ERROR: cannot wait for a standby LSN while holding locks

The same applies after the first query in a REPEATABLE READ transaction (WAIT cannot be executed while the current transaction holds a snapshot). A plain SET LOCAL before it is fine.

Two details cost me time:

An error inside a transaction aborts it (SQLSTATE 25P02), so call WAIT before beginTransaction().
If the target LSN is already reached, WAIT returns immediately even after a query. The restriction only triggers when it would actually have to wait. So your tests can pass on an idle replica and fail in production.

It also can't run inside a DO block or function (WAIT can only be executed as a top-level statement).

Gotcha 3: the docs' LSN function can hang

The documentation example takes the LSN with pg_current_wal_insert_lsn(). In my idle test, 5 out of 5000 waits timed out. Every one of those LSNs had the same page offset: 24 bytes, which is the size of a WAL page header.

0/0322A018   0/03240018   0/03268018   0/032C8018   0/032DE018

My explanation (an inference, not something I checked in the source): the commit record ended exactly at a WAL page boundary, and the insert pointer was reported after the new page's header. The replica has replayed everything that exists, but the target sits 24 bytes past the last real record, so WAIT blocks until more WAL arrives. On an idle system that can be a long time.

With the default synchronous_commit = on, pg_current_wal_flush_lsn() does not have this problem: 0 timeouts in 5000, and it was also slightly faster. Either way, use TIMEOUT and NO_THROW, check the status, and fall back to the primary. Never ignore the returned status.

Gotcha 4: synchronous_commit = off changes everything

If your app uses asynchronous commit, the flush LSN can be behind your commit record:

Primary session with `synchronous_commit = off`	Result
`flush_lsn`, then WAIT	`success` in 48 µs, but 300 / 300 reads were stale
`insert_lsn`, then WAIT	correct, but median wait 201 ms

WAIT dutifully reports success for a position the replica really did reach. It just isn't your write. The insert LSN is correct here, but you pay roughly one wal_writer_delay (200 ms by default) per wait, and 8 of 300 still hit my 300 ms timeout.

So: flush LSN if you use synchronous commit, insert LSN plus the fallback if you don't.

Symfony and Doctrine

Nothing here is tied to PDO. With DBAL, run the same WAIT through executeQuery() on the replica connection, before opening a transaction. One natural place to capture the LSN is a listener that runs after a flush on the primary connection and stores the result in the session. I've only tested the plain PDO version above, so treat that as a design sketch.

Takeaways

Read-after-write against an async replica is broken by default: 5000/5000 stale reads in my test.
WAIT FOR LSN fixes it cheaply: about 0.3 ms idle, about 1.2 ms under write load on my setup.
Always pass TIMEOUT and NO_THROW, check the status, and fall back to the primary.
Validate the LSN yourself, because you can't bind it.
Call it before opening a transaction.
Pick the LSN function to match your synchronous_commit setting.

I ran into this while working on search and read-heavy PostgreSQL workloads for PHP, including Fuzzphony. If you have a real multi-machine setup, I'd love to see your numbers in the comments.

grapheme_levenshtein() in PHP 8.5: what the docs don't tell you

Szj — Wed, 30 Sep 2026 17:23:11 +0000

PHP's levenshtein() has always counted bytes. For English that's invisible. For Hungarian, Polish, Czech, or anything with accents, it quietly lies:

levenshtein('szőke', 'szoke'); // 2, but it's one edit

The ő is two bytes in UTF-8 (C5 91), so the function sees two edits. PHP 8.5 finally adds grapheme_levenshtein(), which counts user-perceived characters instead. Every article I found about it explains the syntax. None of them measured it, so I did.

Setup

PHP 8.5.10 (CLI, built from source), ICU 74.2, default settings, no JIT
Synthetic Hungarian-style words (with sz, cs, ő, ű, ...), each compared with a copy containing one random edit
20,000 pairs per length, best of 3 rounds, nanoseconds per comparison
Single vCPU sandbox: absolute numbers will differ on your machine, the ratios are what matter.

What it fixes

Pair	`levenshtein()`	code points	`grapheme_levenshtein()`
`szőke` vs `szoke`	2	1	1
`Kovács` vs `Kovacs`	2	1	1
`ő` vs `ö`	2	1	1
`é` (NFC) vs `é` (NFD)	3	2	0
👩‍💻 vs 👩	7	2	1

The NFC/NFD row is the real win. The same visible é can be stored as one code point or two (e + combining accent), depending on where the data came from. The byte version reports 3 edits between two strings that look identical. The grapheme version correctly reports 0.

What it costs

Length	`levenshtein()`	`grapheme_levenshtein()`	with `locale='hu'`	userland, code points
8 chars	0.22 µs	3.3 µs	4.0 µs	3.8 µs
24 chars	1.3 µs	14.1 µs	17.6 µs	29.2 µs
64 chars	6.4 µs	76.9 µs	98.2 µs	196.1 µs

Three things stand out:

It is 11-15x slower than the byte version. Correctness isn't free: the function segments both strings into grapheme clusters and compares them through ICU.
It beats a userland implementation by about 1.2x on short strings and 2-2.6x on longer ones. If you were using a pure PHP multibyte Levenshtein, switching is a clear win.
The $locale parameter adds 23-28% on top.

The manual documents the complexity as O(m*n). In practice that means you should not run it over a whole table: at 24 characters, 1M rows is roughly 14 seconds of CPU per query, versus about 1.3 seconds for the byte version.

Two surprises

Invisible characters can compare as equal. In my tests on 8.5.10:

grapheme_levenshtein("\x01", "\x02");          // 0
grapheme_levenshtein("\u{200B}", "\u{200C}");  // 0
grapheme_levenshtein("\x01", "");              // 1

Two different control or zero-width characters are treated as identical to each other, yet each one differs from an empty string. The equality check is a collation comparison, and ICU collation ignores some characters completely. Mid-word cases behave less predictably ("a\u{200B}b" vs "a\u{200C}b" gave 1, while "a\x01b" vs "a\x02b" gave 0). A soft hyphen (U+00AD) is not ignored and costs one edit. This matches a recently reported php-src issue, so check the current status before relying on either behavior.

For search this is mostly harmless, but if you use the distance for deduplication or validation, strip control and format characters first.

The locale parameter changed nothing in my tests. I compared hu against en on every case above, including cs vs c and sz vs s, where you might hope for Hungarian digraph awareness. The results were identical in all cases. It only added the 23-28% cost. I'm not claiming it never matters (I can't rule out effects on other scripts or case-insensitive comparisons), but for Hungarian names it bought me nothing.

Also note that the comparison is case-sensitive: Kovács vs kovács is 1.

So how should you use it?

Don't scan with it, re-rank with it. Let the database produce candidates cheaply and let PHP do the precise scoring on a handful of rows.

-- PostgreSQL + pg_trgm: fast candidate generation
SELECT name
FROM people
WHERE name % :query
ORDER BY similarity(name, :query) DESC
LIMIT 50;

function clean(string $s): string
{
    // strip control/format characters, then lowercase
    return mb_strtolower(preg_replace('/[\p{Cc}\p{Cf}]/u', '', $s));
}

function rerank(string $query, array $candidates, int $maxDistance = 2): array
{
    $q = clean($query);
    $scored = [];
    foreach ($candidates as $name) {
        $d = grapheme_levenshtein($q, clean($name));
        if ($d !== false && $d <= $maxDistance) {
            $scored[$name] = $d;
        }
    }
    asort($scored);
    return $scored;
}

rerank('Szoke', ['Szőke', 'Szűcs', 'Szabó', 'SZOKE']);
// ['SZOKE' => 0, 'Szőke' => 1]

Re-ranking 50 candidates of around 24 characters costs about 0.7 ms (50 x 14 µs), which is nothing next to the query itself. That's the sweet spot: the accuracy of a grapheme-aware distance at a cost you never notice.

Takeaways

Use grapheme_levenshtein() over levenshtein() whenever your data has accents or mixed Unicode normalization.
Expect ~12x the cost of the byte version, and never run it over a full table.
Normalize case and strip invisible characters yourself.
Measure before you reach for $locale.

I ran into all of this while building Fuzzphony, a PostgreSQL-native search library for PHP and Symfony. If you have your own numbers from a different machine or dataset, I'd love to see them in the comments.

I couldn't touch the database, so I built search next to it

Szj — Mon, 28 Sep 2026 18:40:07 +0000

A production system I work on needed a search box that forgives people. They type kavefozo and expect Kávéfőző. They type hedphones and expect headphones.

The constraints were the interesting part:

The schema could not change. No new columns, no generated columns, no migrations on tables that weren't ours.
No new infrastructure. No Elasticsearch, no Meilisearch, no extra service to run, sync, back up and secure.

So search had to happen inside the database that was already there. PostgreSQL turned out to have almost every piece needed. Wiring those pieces together properly was the hard part, and that wiring became an open-source library: Fuzzphony.

Fuzzphony is at v0.4 and still in active development. The core works and is heavily tested, but the API can change before 1.0, and there are rough edges I'll be upfront about at the end.

This post covers the design, the bug that taught me the most, and what I still haven't solved.

What `LIKE '%…%'` gets wrong

Most search boxes start here:

SELECT * FROM product WHERE name ILIKE '%' || :q || '%' LIMIT 20;

It misses typos (hedphones), accents (creme vs crème) and word forms (drills vs drill). It can't exclude a word, it doesn't rank, and when it misses, it reads the whole table to return nothing.

Postgres ships three tools for exactly these problems:

Full-text search (tsvector, tsquery, ts_rank_cd): stemming for 28 languages, field weights A to D, relevance ranking.
unaccent: folds Kávéfőző into Kavefozo.
pg_trgm: trigram similarity, which is what lets wireles match wireless.

None of them is new. The work is in making them behave together, stay in sync with your data, and be safe to point at user input.

The sidecar table

Since your tables are off-limits, the index lives in its own table next to them.

For every index, Fuzzphony keeps a table such as fuzzphony_products with:

a weighted tsvector for full-text search, on a GIN index,
a normalised, unaccented text column for typo tolerance, on a GIN trigram index,
typed filter columns on btree indexes, so where('price', '<=', 20_000) never has to touch your table,
the inputs for ranking: a boost column (popularity, say) and a recency column.

The source can be a single table or any SELECT, joins included. With schema: fuzzphony set, the sidecar tables, the queue and the helper functions all live in their own schema, and dropping an index is one command.

To be precise about "off-limits": no column is ever added, but in the default queue mode and in trigger mode Fuzzphony does attach triggers to the tables it watches. That's how it sees writes from raw SQL, imports and other applications. If even a trigger is too much, the orm and manual modes need none.

The cost of the design is obvious: there is now a second copy of the searchable data, and it has to stay in sync.

Keeping it in sync without hurting writes

There are four sync modes:

Mode	How	When
`queue` (default)	triggers enqueue ids, `fuzzphony:worker` refreshes in batches	most apps; writes stay fast
`trigger`	triggers refresh inside the writing transaction	you need read-your-writes
`orm`	a Doctrine listener refreshes after `flush()`	triggers are not allowed at all
`manual`	nothing automatic	batch imports, read-only data

Three details made the trigger-based modes usable on real tables.

Statement-level triggers with transition tables. A row-level trigger on an UPDATE brand SET … that touches 100 000 rows fires 100 000 times. A statement-level trigger fires once and sees every changed row through a transition table, so queuing the affected products becomes a single set-based statement. In simplified form (not the exact generated SQL):

CREATE TRIGGER brand_sync
AFTER UPDATE ON brand
REFERENCING NEW TABLE AS changed
FOR EACH STATEMENT EXECUTE FUNCTION queue_products_of_changed_brands();

-- inside the function, roughly:
INSERT INTO sync_queue (index_name, doc_id)
SELECT 'products', p.id
FROM changed b
JOIN product p ON p.brand_id = b.id;

Only refresh when something relevant changed. An UPDATE product SET last_viewed_at = now() should not reindex anything. For the index's own table, Fuzzphony checks whether a mapped column actually changed. For joined tables you opt in with columns: ['name'], because a library cannot guess which of a joined table's columns matter to you.

TRUNCATE is not a delete. It fires no DELETE triggers, so early versions left stale documents in the index after a TRUNCATE, and not even a full reindex removed them. I found that one late. Now every watched table also gets an AFTER TRUNCATE trigger, and a full reindex prunes documents whose rows no longer exist.

The worker takes a batch with DELETE … FOR UPDATE SKIP LOCKED and refreshes it in the same statement, so a failed refresh rolls the dequeue back and no id is lost, and several workers can run side by side. If you'd rather not run a long-lived process, fuzzphony:worker --once from cron works too.

What happens to a query

From the application side, a search looks like this:

$result = $fuzzphony->in(Product::class)
    ->query('wireles mouse -cable')          // a typo and an exclusion
    ->where('price', '<=', 20_000)
    ->where('in_stock', true)
    ->highlight('name')
    ->get();

foreach ($result as $hit) {
    echo $hit->id, ' ', $hit->score, ' ', $hit->highlights['name'];   // "<mark>Wireless</mark> mouse"
}

Behind that call, the query goes through a few stages:

A few decisions in there are worth explaining.

User input never throws. Unbalanced quotes, stray operators and absurdly long input are repaired and reported in $result->warnings, and $result->interpretedAs shows how the query was understood. Developer mistakes are the opposite: they fail loudly, with a hint. Index "products" has no filter "prise". Did you mean "price"?

Exact first, typo tolerance as a fallback. Trigram matching is slower and noisier than full-text matching, so by default it only runs when exact matching finds fewer than fallback_below hits.

Typo tolerance is per word. The first version compared the whole query string against the fuzzy fields, so one long common word could satisfy it on its own. On the demo catalogue, wireles mice returned 20 000 products (chairs, drills, kettles), of which 1 666 were mice. Now every word has to match on its own, exactly or by trigram similarity, inside the query's real AND / OR / NOT structure. The same query returns exactly the 1 666 wireless mice.

An empty result gets one more try. If a query of two or more words finds nothing, each word is checked on its own, the words that match nothing are dropped, and the search runs again with a warning saying which words were ignored. wireless mouse aluminum returns the wireless mice instead of an empty page.

Ranking is explainable. The score is a plain formula:

relevance = text  × ts_rank_cd(weights A..D)
          + fuzzy × word_similarity(query, fuzzy fields)

score     = relevance
          + exact_bonus + prefix_bonus
          + boost   × boost column
          + recency × 2^(−age / half_life)

min_score applies to relevance only, so a popularity boost can reorder relevant hits but can never pull an irrelevant one into the results. Every hit carries a score breakdown, so "why is this first?" always has an answer.

The bug that taught me the most

A German test query, Tasche für Laptop, did not find a product called Laptop Tasche. In the French catalogue, searching for à alone matched 13 products. Hungarian és misbehaved the same way.

A text search configuration sends every token through a list of dictionaries, in order. Mine ran unaccent before the Snowball stemmer. The stemmer's German stop-word list contains für, but by the time the token reached it, it had become fur, which is not a stop word. So für was indexed as an ordinary word, and every query containing it had to match it.

The fix was to drop stop words before anything else touches the token, with a stop-word dictionary built from the language's own list. In simplified form:

CREATE TEXT SEARCH DICTIONARY fuzzphony_german_stop (
    TEMPLATE = simple, STOPWORDS = german, ACCEPT = false
);

CREATE TEXT SEARCH CONFIGURATION fuzzphony_german (COPY = german);

ALTER TEXT SEARCH CONFIGURATION fuzzphony_german
    ALTER MAPPING FOR asciiword, word, asciihword, hword, hword_asciipart, hword_part
    WITH fuzzphony_german_stop, unaccent, german_stem;

With ACCEPT = false, the stop dictionary discards stop words and passes everything else on to the next dictionary.

Two things came out of this besides the fix. fuzzphony:doctor now reports a configuration that still keeps accented stop words. And the demo got a Languages page that searches small catalogues in English, German, French, Spanish and Hungarian, and shows the lexeme Postgres produced for every query word. I would have caught this bug on day one if that page had existed earlier.

The numbers, with the caveats

A sample run on 200 000 products, PostgreSQL 16, a small cloud VM, 20 results per query:

Query	ILIKE (warm)	ILIKE hits	Fuzzphony (warm)	Fuzzphony hits
`wireless`	0.6 ms	20, unranked	11.1 ms	20 of 2000+, ranked
`creme`	251.6 ms	0	10.4 ms	20 of 2000+
`hedphones`	252.6 ms	0	20.7 ms	20 of 2000+
`drills`	257.1 ms	0	10.6 ms	20 of 2000+
`"noise cancelling" -headphones`	0.5 ms	20, wrong	23.2 ms	20 of 2000+

Read this carefully, because a benchmark against ILIKE is easy to make look good:

On plain words, ILIKE is much faster. LIMIT 20 without an ORDER BY just returns the first 20 rows the scan happens to hit. Fast, but not the best 20.
The ILIKE baseline has no trigram index, which is why its misses are full table scans. A gin_trgm_ops index would make those rows fast. It would not make them correct: ILIKE '%hedphones%' finds nothing no matter how it is indexed.
ILIKE has no concept of exclusion, so on the last row it silently ignores -headphones.

Run the numbers on your own data before believing anyone's benchmark, including this one. The benchmark script is in the repository, and CI runs it on every push.

When not to use it

Fuzzphony is not the right tool if you need hundreds of millions of documents or thousands of searches per second on one index, analytics-style aggregations, semantic or vector search (look at pgvector or a dedicated engine), or a database other than PostgreSQL.

It fits best where the database is not yours to change (a legacy system, an ERP, tables another team owns), where you are replacing LIKE in admin panels and back offices, or where the data has to stay in the database for compliance reasons.

What I haven't solved yet

Two things are genuinely open, and I'd like opinions on both.

Typo tolerance is too lenient on short words. At the default similarity threshold, mouse also matches monitor: short words have few trigrams, so a single shared one weighs a lot. The plan is length-aware thresholds, probably with trigrams only generating candidates from a vocabulary table and an edit-distance check deciding. How do you tune pg_trgm for short words?

Ranking of very frequent words. A GIN index can find matches but can't return them in relevance order, so for a word that matches tens of thousands of documents, Fuzzphony ranks the first candidate_limit (2000 by default) that the index returns. That's not necessarily the best 2000. For most back-office searches this doesn't show, but it's the real ceiling of doing search inside Postgres, and I'd rather say so than hide it behind "approximate ordering".

Rough edges I'm working on before 1.0

Writing the docs for v0.4 surfaced a few things I'd design differently, so they're on the list:

Trigger privileges. The sync functions run with the privileges of whoever writes the row. In a shared database, every role that writes to a watched table therefore needs grants on Fuzzphony's queue, or its writes fail. Moving the enqueue step into a SECURITY DEFINER function removes that coupling.
A batch that always fails. A refresh that fails deterministically (a document over Postgres' ~1 MB tsvector limit, for example) is rolled back and retried forever, which blocks the queue behind it. It needs a dead-letter path.
Pruning as a default. A full reindex removes documents whose rows it can't see. If the reindexing role sees fewer rows than the application (row-level security, a different search_path), that removes real documents. It should stop and ask above a threshold.
Field scoping leaks into typo tolerance. name:sony can return Sony-brand products, because the fuzzy fields share one trigram column. Per-field columns are planned for 0.5.

None of these show up in a single-app setup with one database role, which is how most people will try it. But they're exactly what bites in the environments Fuzzphony is aimed at, so they come before new features.

Try it

composer require fuzzphony/fuzzphony

Or run the demo, a full Symfony app on a seeded catalogue, with ILIKE and Fuzzphony side by side, a ranking playground with sliders, and a configuration wizard:

git clone https://github.com/er2es/fuzzphony
cd fuzzphony/demo && docker compose up --build    # http://localhost:8000

It requires PHP 8.4+ and PostgreSQL 15+, and is tested on Symfony 7.4 and 8.0 against PostgreSQL 15 to 18. The current release is v0.4 and development is ongoing: breaking changes can still happen before 1.0, and each one is listed in the CHANGELOG with upgrade steps in UPGRADE.md.

I built this with a lot of help from Claude Code. The design decisions are written down as ADRs in the repository, and the heavy testing (PHPStan at max level, 100% line coverage, mutation testing) is partly because of that: when you didn't type every line yourself, tests are how you know what the code actually does.

Feedback is very welcome, in the comments or as a GitHub issue, especially on the two open problems above. If the library looks useful, a star on GitHub helps other people find it.

DEV Community: Szj

The State of Mutation Testing (Infection) in the PHP Ecosystem: A Scientific and Practical Analysis

Abstract

1. Theoretical Background and Methodology

2. The Value Proposition (ROI)

3. Technological Limitations and Critical Analysis

3.1. Combinatorial Explosion and Computational Overhead

3.2. The Equivalent Mutants Problem

3.3. Implementation Challenges in Legacy Systems

4. Modern Optimization Strategies (CI/CD Integration)

5. Conclusion and Architectural Recommendations

Bibliography and References

5 Angular Anti-Patterns You Need to Stop Using Immediately (and How to Fix Them in Angular 21)

1. Function Calls in Templates (The Performance Killer)

2. Abandoned Subscriptions (The Memory Leak)

3. Nested Subscriptions (The Reactive "Callback Hell")

4. "Fat" Components (The God Object)

5. The Desperate ChangeDetectorRef Hack

Wrapping Up

PostgreSQL 19 WAIT FOR LSN from PHP: read-your-writes on a replica, and four ways it bites" published: false

The problem, measured

The fix

Gotcha 1: you can't bind the LSN

Gotcha 2: it must be the first thing in a transaction

Gotcha 3: the docs' LSN function can hang

Gotcha 4: synchronous_commit = off changes everything

Symfony and Doctrine

Takeaways

grapheme_levenshtein() in PHP 8.5: what the docs don't tell you

Setup

What it fixes

What it costs

Two surprises

So how should you use it?

Takeaways

I couldn't touch the database, so I built search next to it

What LIKE '%…%' gets wrong

The sidecar table

Keeping it in sync without hurting writes

What happens to a query

The bug that taught me the most

The numbers, with the caveats

When not to use it

What I haven't solved yet

Rough edges I'm working on before 1.0

Try it

5. The Desperate `ChangeDetectorRef` Hack

What `LIKE '%…%'` gets wrong