Rise of Biological Computers: A Plain-English Guide to Their Research

 

I stumbled on Cortical Labs research page after seeing a headline about brain cells playing Doom. My first reaction was the same as everyone else: okay, that sounds like a meme. Then I read the papers. It is weird. It is also serious science.

Melbourne-based Cortical Labs is trying to build computers from living neurons grown on silicon chips. Not a metaphor. Real cells. Real electrical pulses. Real learning, in a dish, while a digital game runs on the other side of the interface.

Their homepage calls this "Artificial Actual Intelligence." Cheesy label. Interesting point: silicon AI tries to imitate what biology already does. Cortical Labs starts with the biology.

The One-Minute Version

Here is the whole idea in one pass:

1. Grow neurons on a multielectrode array (MEA).
2. Convert game or task state into electrical stimulation patterns.
3. Read neural spikes back out.
4. Decode spikes into actions (move, shoot, paddle up, and so on).
5. Send feedback so the network can adapt over time.

That closed loop is the heart of the work. Without it, you are just poking cells. With it, the culture is embodied in a task. That language comes straight from their landmark 2022 Neuron paper on DishBrain (Kagan et al., 2022).

From Pong to Doom: Why Games Keep Showing Up

In 2021 the team showed neurons learning Pong in a simulated environment. The 2022 paper formalized the setup and reported learning signatures within about five minutes of closed-loop play, which is wild when you remember these are cells in a petri dish, not a trained RL agent burning GPU hours (Kagan et al., 2022).

Internet being internet, people asked the only reasonable follow-up question: can it run Doom?

In 2026 Cortical Labs demonstrated Doom running through the CL1 platform, built with collaborator Sean Cole using their API and Cortical Cloud. Reports describe on the order of 200,000 living human neurons on the chip for that demo, with stimulation patterns encoding game state and spike patterns driving movement and firing. Is it esports-ready? No. Is it a useful stress test for adaptive biological control? Yes.

The game is not the product. The game is a benchmark you can score.

What the CL1 Actually Is

The CL1 is what Cortical Labs calls the world's first code-deployable biological computer. Shipments were announced for researchers who want programmable access to living neural networks without building an entire wet lab stack from scratch.

Important pieces:

• Hardware: neurons cultured on a custom high-density MEA inside a life-support system (Cortical Labs cites up to ~6 months viability).
• biOS: their Biological Intelligence Operating System, which creates the simulated world the neurons interact with.
• Closed-loop I/O: bi-directional stimulation and recording in real time.
• Programmability: Python-accessible APIs so developers can treat the culture like a compute substrate, not a one-off experiment.
• Cortical Cloud: remote access and scaling without every lab owning full infrastructure.

CL1 hardware image from Cortical Labs.

The Science Behind the Headlines: Free Energy and Feedback

The DishBrain work did not use conventional reward labels like a reinforcement learning pipeline with explicit score tensors. It drew on active inference and the free energy principle (Friston, 2010; Kagan et al., 2022).

Plain English version: the system nudges neural cultures toward predictable sensory outcomes when they do something useful, and away from chaotic stimulation when they do not. Over time, activity reorganizes. Synapses shift. The culture behaves less randomly relative to the task.

That is why closed-loop structure matters so much. If the world never reacts to spikes, there is nothing to learn from.

Organoid Intelligence and the Bigger Picture

Cortical Labs sits inside a wider movement sometimes called organoid intelligence (OI) or synthetic biological intelligence (SBI).

The 2023 Frontiers in Science paper "Organoid intelligence (OI): the new frontier in biocomputing and intelligence-in-a-dish" outlines a roadmap for brain organoids as biological hardware, with richer 3D cultures, perfusion, MEAs, machine learning interfaces, and embedded ethics (Smirnova et al., 2023). Brett Kagan from Cortical Labs is among the authors, which tells you how connected these threads are.

Organoid intelligence architecture diagram (CC BY 4.0, Smirnova et al., 2023). Kagan is a co-author. Source: Frontiers in Science.

CL1 today uses neural cultures on MEAs. OI tomorrow may push toward larger, more structured organoids with richer input/output. Same direction: biology as compute.

Walking Through the Research Library

The official research list is not one paper. It is a whole field guide. I grouped the published work the way I wish someone had grouped it for me.

Platform and tooling

• CL API: Real-Time Closed-Loop Interactions with Biological Neural Networks - the software bridge developers actually use.
• The CL1 as a platform technology to leverage biological neural system functions - why the hardware matters as infrastructure, not a one-off demo.

Learning in a game-world

• In vitro neurons learn and exhibit sentience when embodied in a simulated game-world - the DishBrain / Pong paper in Neuron (Kagan et al., 2022).
• Biological Neurons Compete with Deep Reinforcement Learning in Sample Efficiency in a Simulated Gameworld - sample efficiency comparison that gets cited a lot.
• Dynamic Network Plasticity and Sample Efficiency in Biological Neural Cultures - follow-on comparative work with DRL.
• Critical dynamics arise during structured information presentation within embodied in vitro neuronal networks - what happens inside the network when information arrives in structured bursts.

Synthetic biological intelligence as a field

• A Computational Perspective on NeuroAI and Synthetic Biological Intelligence
• Why AI Progress Will Necessitate Harnessing Synthetic Biology to Leverage the Ground Truth of Intelligence
• Two roads diverged: Pathways toward harnessing intelligence in neural cell cultures
• The technology, opportunities, and challenges of Synthetic Biological Intelligence
• Harnessing Intelligence from Brain Cells In Vitro

Organoids, ethics, and definitions

• Organoid intelligence (OI): the new frontier in biocomputing and intelligence-in-a-dish (Smirnova et al., 2023)
• Intersection between the biological and digital: synthetic biological intelligence and organoid intelligence
• Human Neural Organoid Microphysiological Systems Show the Building Blocks Necessary for Basic Learning and Memory
• Neurons Embodied in a Virtual World: Evidence for Organoid Ethics?
• Embodied Neural Systems Can Enable Iterative Investigations of Morally Relevant States
• A Quantifiable Information-Processing Hierarchy Provides a Necessary Condition for Detecting Agency
• Toward a nomenclature consensus for diverse intelligent systems: Call for collaboration

Methods and applications

• A novel protocol for the efficient generation of all three major hippocampal neuronal sub-populations from human pluripotent stem cells - cell sourcing matters for reproducible cultures.
• Drug treatment alters performance in a neural microphysiological system of information processing - one of the most practical near-term use cases: pharmacology on human-relevant neural hardware.
• Active Inference and Intentional Behavior - theory tie-in for the feedback paradigm.
• Starting a synthetic biological intelligence lab from scratch - practical guide for teams entering the space.

Key Papers Worth Reading First

Paper	Year	Why it matters
In vitro neurons learn and exhibit sentience when embodied in a simulated game-world	2022	Foundational DishBrain paper. Defines synthetic biological intelligence and closed-loop embodiment.
Organoid intelligence (OI): the new frontier in biocomputing and intelligence-in-a-dish	2023	Field roadmap for organoid-based biocomputing; connects to Cortical Labs via Kagan.
Biological Neurons Compete with Deep Reinforcement Learning in Sample Efficiency	2023	Direct comparison that makes the "biology learns fast" claim concrete.
The CL1 as a platform technology	2024+	Moves the story from experiment to productized research hardware.
Drug treatment alters performance in a neural microphysiological system	2023	Shows pharma-adjacent value beyond gaming demos.

Real Use Cases (Not Just Doom Memes)

Cortical Labs markets the CL1 for drug discovery, disease modeling, and understanding learning itself. That is more believable than "replace your laptop with a petri dish."

• Neuropharmacology: test compounds on living human-relevant neural tissue and watch information processing change.
• Disease models: compare healthy versus patient-derived neural cultures under identical closed-loop tasks.
• Fundamental neuroscience: study plasticity with precise stimulation and readout at scale.
• Hybrid AI research: pair biological networks with conventional ML encoders/decoders, as in the Doom work with PPO-style training on the digital side.
• Reduced animal testing: Cortical Labs explicitly positions human cell-based systems as an ethically relevant alternative for certain experiments.

Ethics: The Part You Cannot Hand-Wave Away

Once neurons are trained in game-worlds and discussed using words like "sentience" and "agency," ethics stops being optional. Cortical Labs publishes on this directly, including work on organoid ethics, morally relevant states, and nomenclature for diverse intelligent systems.

The honest position: we do not fully know what these cultures experience, if anything. But the research community is already asking the right questions before the hardware gets cheap and widespread. That is better than the alternative.

How This Differs from Normal AI

Topic	Silicon AI	Cortical Labs / SBI
Hardware	GPUs, TPUs, fixed weights in memory	Living neurons on MEAs, physically rewiring over time
Learning	Backprop, huge datasets, offline training	Activity-dependent plasticity during closed-loop tasks
Energy	Large for big models	Biological systems can be far more efficient for some learning tasks
Programmability	Exact, deterministic code paths	Hybrid: digital encoder/decoder plus living substrate you steer, not fully control

What I Take Away

Cortical Labs is not claiming they shipped consciousness in a box. They shipped an interface to living neural computation that you can program. That alone is a category shift.

The research page is worth bookmarking because it spans the full stack: theory (active inference), experiments (Pong, Doom, drug response), platform engineering (CL1, CL API, Cortical Cloud), and ethics. Most labs pick one lane. Cortical Labs is trying to own the whole bridge between wetware and software.

If you are new here, start with the 2022 Neuron DishBrain paper, skim the OI roadmap paper from 2023, then watch the Doom demo with the understanding that the game is a test harness, not the end goal. After that, the rest of the library on corticallabs.com/research reads in order instead of like sci-fi fragments.

Still think biological computing is just a headline? Fair. Read the Neuron paper anyway. The methods section is where the hype goes to get audited.

Bibliography

• Cortical Labs. (2026). Research. https://corticallabs.com/research
• Cortical Labs. (2026). CL1: The world's first code deployable biological computer. https://corticallabs.com/cl1
• Kagan, B. J., Kitchen, A. C., Tran, N. T., Habibollahi, F., Khajehnejad, M., Parker, B. J., Bhat, A., Rollo, B., Razi, A., & Friston, K. J. (2022). In vitro neurons learn and exhibit sentience when embodied in a simulated game-world. Neuron, 110(23), 3952-3969.e8. https://doi.org/10.1016/j.neuron.2022.09.001
• Smirnova, L., Caffo, B. S., Gracias, D. H., Huang, Q., Morales Pantoja, I. E., Tang, B., Zack, D. J., Berlinicke, C. A., Boyd, J. L., Harris, T. D., Johnson, E. C., Kagan, B. J., Kahn, J., Muotri, A. R., Paulhamus, B. L., Schwamborn, J. C., Plotkin, J., Szalay, A. S., Vogelstein, J. T., Worley, P. F., & Hartung, T. (2023). Organoid intelligence (OI): the new frontier in biocomputing and intelligence-in-a-dish. Frontiers in Science, 1, 1017235. https://doi.org/10.3389/fsci.2023.1017235
• Friston, K. (2010). The free-energy principle: a unified brain theory? Nature Reviews Neuroscience, 11(2), 127-138. https://doi.org/10.1038/nrn2787
• Tom's Hardware. (2026). 200,000 living human neurons on a microchip demonstrated playing Doom. https://www.tomshardware.com/tech-industry/artificial-intelligence/200-000-living-human-neurons-on-a-microchip-demonstrated-playing-doom-cortical-labs-cl1-video-shows-the-gameplay-and-explains-how-the-neurons-learn-the-game

Read More

Transfer Files Without Internet: How Decimen Sends Data Through a Screen and a Camera

 

I saw a headline about moving files with QR codes and no Wi-Fi and assumed it was a gimmick. Then I opened decimen.app, pointed one phone at another laptop screen, and watched a PDF rebuild itself from flashing squares. No cable. No Bluetooth pairing. No shared network. Just light.

The project is called Decimen, built by Evan Crawley (Bash Alarmist). Some articles spell it "Desimon," including a recent piece on Geeky Gadgets. Same idea. The real repo lives at github.com/bashalarmistalt/decimen-optical-transfer, where it has picked up thousands of stars for a reason: it solves a narrow problem very cleanly.

The One-Minute Version

Optical file transfer works like this:

1. Device A encodes a file into a stream of animated QR codes on its screen.
2. Device B points a camera at that screen and decodes each frame.
3. After enough distinct frames arrive, the receiver reconstructs the original file.
4. Nothing travels over Wi-Fi, cellular, USB, or Bluetooth between the two devices.

That last point is the whole pitch. You are not "offline syncing through the cloud." You are literally reading pixels. For air-gapped machines, embedded boards with only a camera, or situations where you do not trust any radio stack, that matters.

Why Fountain Coding Changes Everything

Early QR transfer demos often chopped a file into numbered chunks. Frame 1, frame 2, frame 3. Miss frame 2 and you are stuck waiting for the loop to come back around. In bad lighting, with a cheap camera, or when the screen refresh rate and the camera shutter do not line up, dropped frames are normal.

Decimen uses fountain coding, specifically Luby transform codes (Crawley, 2026; Luby, 2002). Instead of shipping unique sequential slices, the sender emits mathematically mixed frames. The receiver needs roughly K × 1.15 distinct frames, in any order, to peel the file back out. A missed frame slows you down. It does not break correctness.

That design fits the channel. A screen-to-camera link has no back-channel. The sender cannot ask "did you get packet 47?" It can only keep flashing codes and hope the camera catches enough of them. Fountain codes were built for exactly that kind of one-way, lossy pipe.

The same fountain-code idea showed up earlier in Ivan Daniluk's txqr project (Divan, 2018), which is worth reading if you want the theory without the browser polish.

What Decimen Actually Ships

Decimen is not a research slide deck. It is a working web app plus open-source codebase (Crawley, 2026):

• No install required. Open decimen.app on two devices. It can cache for offline use and install as a PWA on iOS and Android.
• Files up to 64 MB, or pasted text, with filename and MIME type preserved.
• SHA-256 verification before download is offered, so you know the rebuild matched the sender.
• Optional gzip when compression helps.
• Export as looping animation (APNG or PNG sequence), so a recorded video of the QR stream can be decoded later by any camera pointed at playback.
• Twelve UI languages, with RTL layout where needed.

Important caveat straight from the README: neither mode is encrypted. Anyone with line of sight to the screen can read what is flashing. Decimen gives you isolation from networks, not secrecy from nearby eyes. Treat it like shouting a file across a room, not like end-to-end encryption.

How Fast Is It, Really?

When Geeky Gadgets covered the project, they cited roughly 128 KB/s as a practical ceiling (Horsey, 2026). That matched early impressions. The project has moved since then. Crawley publishes benchmark "receipts" in the repo, and the current records (August 2026, v0.4.0) look like this:

Device pair	Sustained	Peak	1 MB transfer
Desktop monitor to iPhone	418.5 KB/s	601.5 KB/s	2.5 s
Phone to phone	199.2 KB/s	340.8 KB/s	5.1 s

Those numbers are goodput for the whole transfer, not a cherry-picked burst. Still not USB territory. A 10 MB config bundle might take half a minute phone-to-phone. But for logs, keys, firmware patches, or a short video clip into an air-gapped box, that is often fine.

What moves the needle:

• Screen size and brightness. A large, bright panel (the record run used a 49-inch Odyssey G9) gives the camera more pixels per module.
• Camera quality. Better optics resolve denser QR modules, which means more bytes per frame.
• Distance and alignment. Keep the camera square to the screen and close enough that modules stay sharp.
• Refresh vs shutter. LCD ghosting and frame-rate mismatch still cause drops. Fountain coding absorbs the drops, but you pay in time.

Decimen vs LiveDrop and the Rest

Decimen is open source and browser-native. LiveDrop, covered by PetaPixel (Kritsonis, 2025), is a Dutch commercial product chasing the same optical channel with a mobile app and SDK. Both flash dynamic QR-like codes. Both work without Wi-Fi or Bluetooth between devices. The differences are mostly product shape and tuning.

Project	Access	Reported speed	Notes
Decimen	Free web app + AGPL source	Up to ~419 KB/s sustained (published benchmarks)	Fountain codes, SHA-256 check, 64 MB cap, no account
LiveDrop	iOS/Android app, paid Windows tier, SDK	~700 kbps in 2025; testing 2.6 Mbps	Long-range optics (hundreds of meters with telephoto lenses), optional encryption keys
txqr	Open source (Go)	Varies by setup	Early animated QR + fountain code reference implementation
libcimbar	Open source	Higher density than QR	Custom color barcode instead of standard QR modules

LiveDrop's team talks openly about optics as the bottleneck (Kritsonis, 2025). Phone cameras with wide apertures work well at short range. A 600 mm lens on a proper camera body can stretch the link to hundreds of meters. They are also experimenting with grey/blue tones and infrared for night transfers. Decimen stays pragmatic: standard QR modules, browser decoder built on ZXing, and reproducible benchmark JSON in the repo so skeptics can verify claims.

Crawley notes similar ideas arrived independently elsewhere, including airgapped-qr-code-transfer, which uses sequential chunking instead of fountain frames. Convergent evolution, not copying.

Where This Actually Gets Used

Most people will never need optical transfer. For the cases that do, it is oddly elegant:

• Air-gapped systems. Push a patch or config onto a machine that never touches a network. The data path is visible light only.
• Embedded and industrial gear. A laptop screen facing a controller with a camera module, no USB port exposed.
• Remote or disconnected sites. Two laptops on a worksite with no router. Still faster than retyping hex.
• Cross-platform friction. No Apple/Google ecosystem negotiation. If it has a browser and a camera, it can receive.
• Pre-recorded drops. Export the QR animation, play it on a monitor in a lab video, and let receivers decode from the recording.

Geeky Gadgets frames the security angle as keeping data off external networks (Horsey, 2026). That is fair, with one correction: optical transfer is not automatically "secure." It is network-isolated. Shoulder surfers, cameras in the room, and recorded screens are all in scope.

Practical Tips If You Try It Today

I am not going to pretend setup is zero-friction. It is simple, not magic.

1. Open decimen.app/send/ on the sending device and load your file.
2. Open the receive page on the other device and grant camera access.
3. Maximize brightness, kill night mode, and reduce glare if you can.
4. Hold the receiver steady. Let the progress bar climb. Fountain coding means stutters are fine; giving up early is not.
5. Wait for the SHA-256 check before saving.

Developers can clone the repo, run npm install and npm run dev, and hit the local HTTPS server from a phone on the same LAN for testing (Crawley, 2026). There is also a npm run benchmark path if you want to publish your own receipt.

Limits Worth Knowing Up Front

Optical transfer is a specialty tool, not a replacement for AirDrop or a cable:

• Speed caps. Even hundreds of KB/s is tiny next to gigabit Ethernet.
• No encryption by default. Decimen is explicit about this. LiveDrop can layer access keys, but the channel is still visible.
• Hardware tuning. Ghosting on LCD panels, rolling shutter, and autofocus hunting all eat frames.
• Line of sight. Obstructions and glare are failure modes, not edge cases.
• Human patience. Large media works in theory (64 MB). In practice you will choose smaller files unless you are committed.

That is the honest trade. You gain a data diode made of photons. You lose bandwidth and confidentiality unless you add other layers.

Decimen turns a screen and a camera into a one-way file pipe with no network stack in the middle. Fountain coding is the reason it survives real-world frame drops. LiveDrop pushes the same idea toward commercial speed and long-range optics. Both sit in a growing family of optical exfiltration and sideload tools that sound like spy fiction until you need them on a factory floor.

If you have ten minutes and two devices, try the live demo. Watching a file materialize from blinking QR codes is the fastest way to decide whether this belongs in your toolkit or stays a neat party trick. For me, it crossed from gimmick to "oh, I would use this on an air-gapped laptop" somewhere around the first successful SHA-256 match.

Bibilography

• Crawley, E. (2026). Decimen optical transfer: Fountain-coded QR file transfer [Computer software]. GitHub. https://github.com/bashalarmistalt/decimen-optical-transfer
• Divan. (2018). txqr [Computer software]. GitHub. https://github.com/divan/txqr
• Horsey, J. (2026, August 12). Transfer files without internet using optical QR codes. Geeky Gadgets. https://www.geeky-gadgets.com/transfer-files-without-internet/
• Kritsonis, T. (2025, March 9). LiveDrop wirelessly moves data using dynamic QR codes and cameras. PetaPixel. https://petapixel.com/2025/03/09/livedrop-wirelessly-moves-data-using-dynamic-qr-codes-and-cameras/
• Luby, M. (2002). LT codes. In Proceedings of the 43rd Annual IEEE Symposium on Foundations of Computer Science (pp. 271-280). IEEE.

Read More

What Is Fuzzy Search? Complete Guide with Algorithms, Python Examples, and Flowcharts

 

Last week I was helping a friend wire up search on a small e-commerce site. She typed "wireles mouse" into the admin panel to test it. Exact match? Nothing. The product was listed as "Wireless Mouse, Logitech M185." Her face said it all: the search is broken.

It wasn't broken. It was just too strict.

That's the gap fuzzy search fills. You give it a messy string (typos, missing letters, swapped characters, abbreviations) and it still returns results that a human would recognize as relevant. Not magic. Just math that understands humans are sloppy typists.

What Fuzzy Search Actually Is

Regular search is binary: either the text matches or it doesn't. SQL LIKE, basic Elasticsearch term queries, Ctrl+F in your browser. All of that lives in exact-match land.

Fuzzy search assigns a similarity score between your query and each candidate string. You pick a threshold, return everything above it, and sort by score. "wireles" and "wireless" score high. "wireles" and "wrenches" score low.

The fuzzy part is the tolerance. You're not asking "is this identical?" You're asking "is this close enough that a reasonable person meant this?"

Three things usually define how it behaves:

1. Distance metric: how you measure "closeness" (Levenshtein, Jaro-Winkler, etc.)
2. Threshold: minimum score to count as a match
3. Candidate set: what you're searching through (product names, user records, file paths)

Get those three wrong and you'll either miss good results or flood the user with garbage. There's no free lunch.

Algorithms People Actually Use

There's a whole zoo of string similarity algorithms. You don't need all of them. Here's what shows up in real projects.

Levenshtein Distance (Edit Distance)

The workhorse. Counts the minimum number of single-character edits (insert, delete, substitute) to turn string A into string B.

"kitten" → "sitting" needs 3 edits (k→s, e→i, append g). Distance = 3.

Simple to explain, easy to implement, well understood. Downside: it treats every character equally. A typo at the start of a long product SKU hurts the same as one in the middle, which isn't always what you want.

Time complexity: O(m × n) for strings of length m and n. Fine for short strings. Painful if you're comparing one query against a million long documents naively.

Damerau-Levenshtein Distance

Same as Levenshtein, but also counts transpositions (adjacent swapped chars) as a single edit.

"hte" → "the" = 1 edit, not 2. This matters a lot for typos. People transpose keys constantly ("teh", "recieve", "adn").

Most production fuzzy matchers I've touched either use this or Levenshtein with transposition handling baked in.

Jaro and Jaro-Winkler

Jaro looks at matching characters and transpositions relative to string length. Jaro-Winkler adds a bonus when the first few characters match, which helps with names and prefixes.

"MARTHA" vs "MARHTA" scores ~0.94 with Jaro-Winkler. Good for person names, company names, anything where the beginning of the string carries more signal.

Elasticsearch's fuzzy query uses a variant of this family under the hood for short terms.

n-gram / Q-gram Similarity

Break strings into chunks of n characters and compare the overlap.

"night" with bigrams (n=2): ni, ig, gh, ht
"nigth" with bigrams: ni, ig, gt, th
Three out of four overlap → decent similarity despite the transposition.

Works well when word order shifts or when you're matching substrings inside longer text. PostgreSQL's pg_trgm extension uses trigrams (n=3) and it's surprisingly fast with the right index.

Phonetic Algorithms (Soundex, Metaphone, Double Metaphone)

These don't compare spelling. They compare how words sound.

"Smith" and "Smyth" map to similar phonetic codes. Useful for name matching in CRM systems, patient records, legacy databases where the same person was entered six different ways.

Don't use phonetic matching alone for product search. "night" and "knight" sound alike but mean different things.

Bitap / Shift-Or (Approximate String Matching)

Classic algorithm for "find pattern P in text T with at most k errors." Used internally by ripgrep, GNU grep with -P, and a lot of bioinformatics tooling.

Less common in application-level search UIs, but worth knowing if you're building low-level text engines.

BK-Trees and Metric Trees

These aren't similarity algorithms. They're data structures that make fuzzy search scalable.

A BK-tree organizes strings so that when you're looking for everything within distance k of a query, you can skip huge chunks of the tree without examining every node. Without this (or something like it), brute-force fuzzy search dies the moment your catalog crosses ~50k items.

How Fuzzy Search Flows (End to End)

Here's the pipeline I usually sketch on a whiteboard before writing code:

Step by step in plain English:

1. User types something ugly like "iphone 15 pro maxx".
2. You normalize it: lowercase, strip extra spaces, maybe expand abbreviations.
3. You don't compare against every row in the database (unless you're prototyping). You pre-filter: trigram index, prefix match, or an inverted index narrows candidates from 2 million to 200.
4. Run your similarity function on those 200 candidates.
5. Drop anything below your threshold.
6. Re-rank: exact matches on top, then fuzzy matches, maybe weighted by sales rank or click history.
7. Return the top 10. Done.

The pre-filter step is where most "fuzzy search is slow" complaints come from. Skip it and you'll blame the wrong algorithm.

Where You'll Actually Use This

• E-commerce search: the obvious one. Typos, brand misspellings, "samsng tv" should still find Samsung.
• Autocomplete / typeahead: users hammer keys fast. Fuzzy matching behind the dropdown saves a lot of "no results" dead ends.
• Duplicate detection: merging customer records, deduplicating uploaded CSVs, finding "Jon Smith" and "John Smyth" in the same dataset.
• Log and error search: "NullPinterException" should surface NullPointerException stack traces. DevOps folks will thank you.
• Fuzzy command matching: CLI tools, chatbots, internal admin panels where users guess command names instead of reading docs. (I've built three of these. Nobody reads docs.)
• Record linkage / data cleaning: government datasets, healthcare, finance. Same entity, different spellings across systems.
• Code search: less common, but symbol fuzzy matching helps when you half-remember a function name.

Python Examples You Can Run Today

Option 1: rapidfuzz (what I'd reach for in 2026)

Fast, maintained, drop-in replacement for the older fuzzywuzzy. Written in C++ under the hood.

# pip install rapidfuzz

from rapidfuzz import fuzz, process

products = [
    "Wireless Mouse, Logitech M185",
    "Wired Keyboard, Mechanical RGB",
    "USB-C Hub 7-in-1",
    "Samsung 55-inch QLED TV",
    "iPhone 15 Pro Max 256GB",
]

query = "wireles mouse"

# Single pair comparison
score = fuzz.ratio(query.lower(), products[0].lower())
print(f"Ratio score: {score}")  # ~85+ depending on punctuation handling

# Best matches from a list
matches = process.extract(
    query,
    products,
    scorer=fuzz.WRatio,       # handles partial matches well
    score_cutoff=60,          # ignore weak matches
    limit=3,
)

for name, match_score, idx in matches:
    print(f"{match_score:5.1f}  {name}")

WRatio picks the best scoring strategy automatically (ratio, partial ratio, token sort). For product search with multi-word names, it usually outperforms plain ratio.

Option 2: Pure Python Levenshtein (no dependencies)

Good for understanding what's happening under the hood. Not what you'd ship to production at scale.

def levenshtein(a: str, b: str) -> int:
    if len(a) < len(b):
        return levenshtein(b, a)

    if not b:
        return len(a)

    prev_row = list(range(len(b) + 1))
    for i, ca in enumerate(a, start=1):
        curr_row = [i]
        for j, cb in enumerate(b, start=1):
            insert_cost = prev_row[j] + 1
            delete_cost = curr_row[j - 1] + 1
            replace_cost = prev_row[j - 1] + (ca != cb)
            curr_row.append(min(insert_cost, delete_cost, replace_cost))
        prev_row = curr_row

    return prev_row[-1]


def similarity(a: str, b: str) -> float:
    dist = levenshtein(a.lower(), b.lower())
    max_len = max(len(a), len(b))
    return 100.0 * (1 - dist / max_len) if max_len else 100.0


candidates = ["wireless", "wireles", "wreless", "wrench", "mouse", "house"]
query = "wireles"

ranked = sorted(candidates, key=lambda w: similarity(query, w), reverse=True)
for word in ranked:
    print(f"{similarity(query, word):5.1f}  {word}")

Option 3: PostgreSQL trigrams (database-side)

If your data already lives in Postgres, enable the extension and let the database do the heavy lifting:

CREATE EXTENSION IF NOT EXISTS pg_trgm;

-- Index for speed (do this on columns you search often)
CREATE INDEX idx_products_name_trgm ON products USING gin (name gin_trgm_ops);

SELECT name, similarity(name, 'wireles mouse') AS score
FROM products
WHERE name % 'wireles mouse'   -- % operator = similarity above threshold
ORDER BY score DESC
LIMIT 10;

I've used this on a project with ~800k product rows. With the GIN index, sub-100ms queries. Without it, table scans and coffee breaks.

Option 4: Elasticsearch fuzzy query

When you're already on Elastic for full-text search, adding fuzziness is one line, but tune it carefully:

{
  "query": {
    "match": {
      "product_name": {
        "query": "samsng tv",
        "fuzziness": "AUTO",
        "prefix_length": 2
      }
    }
  }
}

prefix_length: 2 means the first two characters must match exactly. Stops "tv" from matching "tuv" and every other two-letter accident. Small detail, big difference in result quality.

Scalability: Where It Gets Hard

Brute-force fuzzy search is O(n × m × k) in the worst case: n candidates, average string length m, edit distance limit k. That math catches up fast.

Here's what actually works at scale:

1. Never scan everything

Use inverted indexes, trigram indexes (Postgres GIN, Elasticsearch n-grams), or prefix tries to cut candidates before fuzzy scoring. Target: reduce millions to hundreds, then run the expensive algorithm.

2. Set a max edit distance

Allowing distance 3 on a 4-character query ("ipod") matches almost everything. Rule of thumb I follow:

Query length	Max edit distance
1-2 chars	0 (exact only)
3-5 chars	1
6+ chars	2

Elasticsearch AUTO fuzziness follows similar logic. Short terms get less slack.

3. BK-trees and VP-trees for in-memory catalogs

If you're matching against a few hundred thousand strings in memory (say, a cached product catalog), a BK-tree built on Levenshtein distance prunes search space aggressively. Libraries like pybktree exist, though many teams roll a simpler trigram pre-filter instead because it's easier to reason about.

4. Batch and cache

Popular queries repeat. Cache "iphone" → top results for 5 minutes. At one retailer I worked with, the top 200 queries covered ~40% of all searches. Caching those fuzzy results dropped p95 latency noticeably.

5. Move fuzzy work offline

For duplicate detection or record linkage across millions of rows, don't do it at query time. Pre-compute candidate pairs with blocking (same first letter + same length bucket, same phonetic code, same zip code) and run fuzzy matching in a batch job.

6. Know when NOT to use fuzzy search

Semantic search ("comfortable shoes for standing all day") isn't a typo problem. That's embeddings + vector search. Different tool. I've seen teams bolt fuzzy matching onto every search field and wonder why results feel random. Match the technique to the failure mode.

Rough capacity guide from experience (not benchmarks; your mileage varies):

Approach	Corpus size	Latency target	Notes
Naive Python loop	< 1,000 items	OK for prototypes	Ship something else
rapidfuzz + pre-filter	10k-500k	tens of ms	Sweet spot for app-level search
Postgres pg_trgm + GIN	100k-10M rows	10-200 ms	Great if data is already in PG
Elasticsearch fuzzy	1M+ docs	20-100 ms	Needs cluster tuning
BK-tree in memory	100k-1M strings	single-digit ms	Good for dedicated matching services

Tuning Tips That Save You a Support Ticket

• Normalize before comparing. Lowercase, Unicode normalization (NFKC), collapse whitespace. "Café" vs "cafe" shouldn't depend on whether someone typed an accent.
• Score alone isn't enough. Boost exact matches. Penalize matches where the edit happens in the first character. "BApple" matching "Apple" is usually wrong.
• Test with real typos. Grab a week of search logs (anonymized) and find queries with zero results. Those are your test cases. Made-up examples miss the weird stuff users actually type.
• Watch false positives. Fuzzy search that returns "horse" for "house" erodes trust fast. Tighten threshold or require more of the query to match.
• Measure click-through. A result that scores 72 but nobody clicks is worse than one that scores 85 and gets clicks. Business metrics beat math metrics.

Wrapping Up

Fuzzy search isn't one algorithm. It's a pipeline. Pick a similarity metric that fits your data (Levenshtein for general text, Jaro-Winkler for names, trigrams for partial matches, phonetic for spoken-alike). Pre-filter so you're not comparing against the world. Tune thresholds with real traffic, not gut feel.

My friend's e-commerce search? We added trigram pre-filtering in Postgres plus rapidfuzz for the final ranking on the top 50 candidates. "wireles mouse" found the Logitech mouse on the first try. She stopped Slack-messaging me about it, which I consider a success metric.

Start simple. Ship rapidfuzz or pg_trgm. Optimize when the profiler tells you to, not before.

References

• Levenshtein, V. I. (1966). Binary codes capable of correcting deletions, insertions, and reversals. Soviet Physics Doklady, 10(8), 707-710.
• Winkler, W. E. (1990). String comparator metrics and enhanced decision rules in the Fellegi-Sunter model of record linkage. Proceedings of the Section on Survey Research Methods, American Statistical Association.
• rapidfuzz documentation: https://github.com/rapidfuzz/RapidFuzz
• PostgreSQL pg_trgm: https://www.postgresql.org/docs/current/pgtrgm.html
• Elasticsearch fuzzy query: https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-fuzzy-query.html

Read More