/
.webp)
Generated by Master Biographer | Source for LinkedIn Content
Catania sits at the foot of Mount Etna on the eastern coast of Sicily. The volcano is never quite dormant. It steams. Locals do not find this alarming. They have lived inside its shadow for three thousand years and have decided that some things simply cannot be controlled, only accommodated.
Salvatore Sanfilippo grew up ninety kilometers to the southwest, in Campobello di Licata — a town in the agricultural interior, close to Gela, in the part of Sicily that does not make travel brochures. Not the baroque piazzas of Syracuse or the tourist ferries to Palermo. The inland south: dry, ancient, provincial, and quietly proud.
His father was an electrician at a petrochemical plant. In the early 1980s, his father came home one day with a Z80 processor board — a raw circuit board you had to wire yourself before it would do anything. Then a Texas Instruments TI-99/4A home computer, when Salvatore was about six years old. His father wrote programs in BASIC. The boy watched, learned to type, and began copying the programs by hand. He was in first grade.
By fourteen, the usual forces intervened — motorcycles, girls, the slow social gravity of a Sicilian adolescence — and computing receded. Then, at eighteen or nineteen, something pulled him back. Not programming, exactly. 3D modeling. Games. The aesthetics of the machine. He enrolled at the University of Palermo to study architecture, a degree he would never finish, and began using BASIC to draw.
Then he bought the wrong thing at a computer shop.
In the mid-1990s, Salvatore went to purchase a graphics card. He came home with a modem instead. It is not clear whether this was confusion or impulse or fate, but the distinction does not matter. He plugged it in. He found the internet. He discovered a vulnerability in the Unix ping program — a way to use ICMP signals to bypass packet-sending restrictions — and posted his findings to the Bugtraq mailing list in April 1998.
The next morning, a security company in Milan called him.
The owner of SECLAB told him: "Go on with your life. But read these ten books. Then come back to me."
So that summer — twenty-one years old, no computer science degree, no formal training in security, in a family that was not wealthy — Salvatore Sanfilippo sat on the beaches of Sicily and read everything. Networking. Protocols. Operating systems. The architecture of things that break.
When he came back, they hired him.
The Idle Scan attack is still in Nmap — the most widely used network security scanner in the world. It is listed in its documentation as an advanced technique. Most people who use it do not know who invented it.
Sanfilippo discovered it in late 1998, after moving to Milan. He had been experimenting with hping, a tool he built to send custom TCP/IP packets — more powerful than the standard ping, able to probe through firewalls, test network configurations, slip past the things administrators thought were secure. While manipulating packets, he noticed something: operating systems incremented a sequence field on outgoing traffic in a predictable, monotonic way. That was an information leak. If you could read those increments from a third machine, you could fingerprint network activity without ever showing your own IP address. Blind port scanning. Invisible to the target.
He wrote it up with a colleague late one night, both of them fairly drunk, and sent it to Bugtraq. The email was, by his own later admission, genuinely delirious in its phrasing. It did not matter. The technique was real. It spread across the security community and was eventually implemented by Fyodor Vaskovich directly into Nmap, where it remains. Sanfilippo was twenty-one.
He spent several years in security work — hping, the idle scan, a reputation that preceded him. Then he stopped caring about it. The security world, he decided, was not where he wanted to live. The work felt reactive, adversarial, paranoid. He wanted to build things, not probe them.
In 2000 he joined Linuxcare Italia, a remote position that suited him — he could stay in Sicily, work on Linux infrastructure, earn a salary without relocating to the north. Then the dot-com bubble collapsed. Linuxcare shut down with one month's notice. Salvatore was twenty-three, had a child to support, and was back in Sicily writing PHP for client projects.
He was good at it. He was bored by it.
In 2005, he and a friend named Fabio Pitrola started a company. They called it Merzia — named after a piece of Sicilian slang that Salvatore had been using for years. Merz. It meant something that appeared foolish or worthless but had, underneath, a kind of technical hack value. Something that worked by being strange. Telecom Italia bought two of their Web 2.0 projects. Things were moving.
Then Salvatore built LLOOGG.
The year is 2007. Google Analytics exists, but its real-time feature does not — that will not arrive until 2011. Salvatore has an idea: what if website owners could watch their visitors in real time? Not reports the next morning. Not hourly summaries. Right now. This page. This visitor. This path through the site.
He called it LLOOGG. He pointed it at bloggers who wanted to understand their readers. He embedded a small JavaScript snippet that fired every time a page loaded. Every single page view became a write operation to the database.
He used MySQL.
MySQL is a relational database. It is very good at many things. It is built for disk. When it reads, it reads from disk. When it writes, it writes to disk. The disk spins, the head moves, the latency accumulates. At low volume this is invisible. At high volume — page views from dozens of sites, arriving continuously, each one demanding a write — the disk becomes a bottleneck. The response times grow. The site grinds.
Sanfilippo understood the problem with physical clarity: MySQL was fast enough for most applications because most applications had time to wait. LLOOGG did not have time to wait. Real-time analytics meant what it said. The data had to be written before the next request arrived, and the next one was already arriving.
He tried everything MySQL offered. Tuning. Indexing. Query optimization. Caching layers. The fundamental problem did not move, because the fundamental problem was not MySQL's configuration. It was MySQL's architecture. A write-intensive real-time system needed something that could hold its data in memory — not write through to disk on every operation, but keep the working set alive and fast, and persist to disk only on its own schedule.
He began thinking about a different kind of database.
In early 2009, he built a prototype. He wrote it in Tcl — a scripting language he had been working with on another project, Jim Tcl, a lightweight interpreter. The prototype was approximately 300 lines of code. He called it LMDB: the LLOOGG Memory Database. It was not elegant. It was a sketch. But the sketch contained, already, the essential ideas:
Non-blocking I/O for client connections. Millisecond-granularity key expirations. Fork-based snapshots — rather than writing every change to disk, the process would fork itself, and the child process would serialize memory to disk in the background while the parent kept serving requests. The protocol was human-readable: prefixed-length commands, fast to parse, easy to debug. The data types were not just key-value strings. There were lists. You could push to the left or right. The name of the command in the Tcl prototype — lpush, rpush — would survive, unchanged, into the final product.
He later found this code in an old email and shared it publicly. Looking at it, he noted that even this 300-line throwaway already "had hints about how to perform future developments." The fork for persistence. The data structures. The protocol. It was all there, embryonic, waiting to be rewritten in a language that could actually carry it.
Tcl had reached its limits. It was time to write it in C.
The exact moment is not recorded. There was no manifesto, no journal entry, no dramatic break. There was just a man in Sicily who had a startup that was failing because his database was wrong, and who had, over the preceding months, convinced himself that he understood exactly what the correct database would look like.
He opened a C file and began.
The full name he gave it was REmote DIctionary Server. Redis. A server that you talked to remotely and that acted like a dictionary — you put things in, you got things out, except the things you put in were not just strings but lists and sets and more complex structures, and the things you got back were not just values but the results of operations you had performed on those structures. It was not a simple key-value store. It was something more like a data structure server — a database that looked, in his own description, "like an interpreter for commands."
He wrote it alone, in Catania, working on top of his existing startup work. The port he assigned it: 6379. On a phone keypad, 6379 spells MERZ — the same Sicilian slang that had named his company. The same word for something that looked like nothing but worked by being strange.
By February 10, 2009, he had a version. Approximately 2,000 lines of C. He sent it to a developer friend named Uwe Klein. Two weeks later — February 25, 2009 — he had version 0.2: 3,700 lines. The TODO list from the first version read like a manifesto: clients timeout, background and foreground save, set/get/delete/exists/incr/decr, list operations, sort lists, set operations, expire, keys pattern. Almost everything Redis would become was already on the list on the day it was first sent to a single developer.
That same day, his friend David Welton posted a link to Hacker News.
The Hacker News post did not catch fire.
David Welton posted it. Five people responded. Three of them said there were already similar projects. One person said nothing useful. One person offered to help.
That one person was Ezra Zygmuntowicz.
Ezra was already well-known in the Ruby on Rails community — co-founder of Engine Yard, one of the most respected engineers in the Rails ecosystem. He looked at what antirez had built and saw something the other four respondents had missed. He wrote the initial Ruby client for Redis — redis-rb — and he tweeted about it. The Rails community listened to Ezra. They used redis-rb. They started experimenting.
In March 2009, antirez built Retwis — a minimal Twitter clone in PHP and Redis, a few hundred lines, designed to show what Redis could do with lists and sorted sets. It was a demo, a teaching tool, a proof of concept made tangible. Developers could read it and understand immediately how Redis's data types mapped to real problems.
Then GitHub happened.
Chris Wanstrath, co-founder of GitHub, was dealing with background job processing. Ruby's existing solutions were fragile. He built Resque — a job queue backed by Redis — and open-sourced it in August 2009. GitHub was running millions of jobs through it. The Rails community adopted Resque en masse. Redis went from "interesting experiment" to "thing GitHub runs on" in a single summer.
Then Instagram reached out. Co-founder Mike Krieger emailed antirez directly. Instagram's early architecture was, in Krieger's own description, "entirely built on Redis." The platform that would eventually have a billion users was running on software written by one man in Sicily eighteen months earlier.
Then Twitter invited antirez to their headquarters. Multiple times. They were rebuilding their timeline system and wanted to use Redis for it. They flew a self-taught developer from Catania to San Francisco to sit in their offices and help them think through the architecture.
Antirez had a day job. He was still running LLOOGG. He was responding to bug reports and feature requests in his evenings and weekends. Redis was growing faster than one person could maintain it outside of working hours, and he knew it.
In early 2010, the calls started coming in.
Companies were asking to hire antirez to work on Redis full-time. The condition that had seemed impossible a year before — being paid to write open source software — was now a negotiation between competing offers.
He chose VMware.
The reason he chose them is specific and worth recording: VMware was a technology company, and their first conversations were about technology. Not revenue projections, not market share, not enterprise sales cycles. VM internals. Redis optimization. The architecture of virtualized memory. They spoke the same language.
VMware's offer was simple to the point of sounding implausible: "You just continue what you're currently doing. We'll pay you. All you need to do is mention on your website that Redis is sponsored by VMware." He would stay in Sicily. He would set his own pace. He would develop Redis the way he had always developed it — with full control over direction, design, and release. Redis would remain completely open source. Not open-core, not source-available, not "community edition." Open source.
VMware would even open-source Redis Tools, a set of utilities antirez had built alongside Redis. That had been VMware's idea, not his.
He signed. In March 2010, Salvatore Sanfilippo became a paid open source developer, working from his home in Catania, on software running inside companies whose servers held hundreds of millions of users.
Redis was now everywhere. Not in the way that a startup goes viral. In the quieter, more permanent way that infrastructure spreads — silently, through apt-get install and Heroku add-ons and GitHub dependencies, into the guts of applications that had never mentioned it in their marketing. You were using it without knowing it. Billions of operations per day routed through code written by a man who had bought a modem instead of a graphics card in the 1990s and followed the thread wherever it led.
For eleven years, antirez was Redis.
He was the BDFL — the Benevolent Dictator for Life — in the open source tradition. Every architectural decision went through him. Every new data type, every persistence mechanism, every protocol change. He held the entire system in his head the way a master craftsman holds a piece of furniture: not as an abstraction, but as a physical thing, with grain and weight and specific places where it would fail under load.
VMware became Pivotal in a corporate split. He moved with it. Pivotal eventually connected him to Redis Labs — originally called Garantia Data — the first company built entirely around Redis consulting and managed services. A shared investor suggested the move. Antirez joined Redis Labs as the project's primary maintainer and eventually, in August 2021, Redis Labs officially renamed itself Redis, the company and the project now sharing a single word.
He did not love the maintenance.
This is an important distinction. He loved writing Redis. He did not love maintaining it. The difference is not obvious to people who have not felt it, but to people who have, it is the entire problem. Writing is generative. Maintenance is custodial. Writing is the moment of creation — a problem and a blank file and a solution arriving line by line. Maintenance is the endless management of what has already been created: bug reports, edge cases, backward compatibility, security patches, the constant negotiation between what you want to build next and what the users need you to fix right now.
He kept going for a decade because Redis needed him to. Because the code was deployed on millions of servers and the people who depended on it were running real businesses and he felt, genuinely and not merely professionally, responsible.
But the programming was, in his own telling, a form of art. Every character and line break had to be considered. "I write code in order to express myself," he wrote later. "I consider what I code an artifact." The pressure of the open source community — the feature requests, the issue tracker, the constant pull toward something that was good enough rather than right — was the pressure of a gallery owner telling a painter to make the work more commercially appealing.
He had a phrase for it: he would rather be remembered as a bad artist than a good programmer.
On June 30, 2020, Salvatore Sanfilippo published a blog post at antirez.com.
The title was "The end of the Redis adventure."
He wrote: "Redis was the most stressful thing I did in my career, and probably also the most important." He wrote that he was stepping back as maintainer — not quitting entirely, but moving into an advisory role, handing control to the Redis Labs engineering team. He wrote that for years he had been asked more and more to maintain and less and less to create, and that this was exactly what Redis needed but not what he wanted, and that he had stretched himself through it long enough.
"Now I'm asked more and more," he wrote, "to express myself less and to maintain the project more."
It was not a bitter post. It was a tired one — tired in the way that someone is tired after finishing something genuinely large, when the adrenaline has been gone for years and the discipline alone has been carrying the work. He did not want sympathy. He wanted, as he put it, to return to programming as a form of exploration rather than obligation.
He moved back to writing — actual prose writing. In July 2022 he published a science fiction novel called Wohpe, about artificial intelligence. He still lives in Catania. He still codes: low-level C, embedded systems, microcontrollers, the things that interest him because they are hard and specific and require total attention. He keeps a ZX Spectrum in his office, the same species of machine his father brought home when Salvatore was six.
In December 2024, antirez returned to Redis in an advisory role, amid industry turbulence over the project's licensing changes and the rise of Valkey, an open source fork. The community, predictably, rallied at his reappearance. Some pieces of infrastructure have a human face, and for Redis, that face has always been his.
Here is the thing about Redis that is almost impossible to convey:
You are using it right now.
Not necessarily in the sense that your browser is hitting a Redis server this instant, though it might be. In the larger sense. The applications you use daily — the social media platforms, the e-commerce sites, the SaaS tools, the developer infrastructure — almost all of them have Redis inside. Session management. Rate limiting. Leaderboards. Real-time notifications. Job queues. Pub/sub messaging. Caching layers. The list of things Redis is used for grew, over fifteen years, to encompass almost every pattern of fast, temporary, structured data access.
It is one of the most deployed pieces of software in the world. It sits on more servers than most people who know the word "Redis" have ever thought about. Developers who have never typed a single Redis command have written applications that depend on it three layers down the stack.
And the reason it exists is not a research paper or a venture capital pitch or a product roadmap. The reason it exists is that a self-taught programmer in Catania, Sicily, was building a real-time analytics tool in 2007 and couldn't make MySQL go fast enough, and he was the kind of person who responds to that situation not by switching tools or lowering his ambition, but by building something better and then giving it away.
He named the port after a piece of Sicilian slang that described something foolish-seeming but technically clever.
He turned out to be right.
A man builds a tool for his own startup. He posts it on Hacker News. Five people respond. Fifteen years later it's running inside half the internet.
Ezra Zygmuntowicz was the only person who offered to help in the original Hacker News thread. He wrote the Ruby client. That client got Redis into Rails. Rails got Redis into GitHub, then Twitter, then Instagram. One yes, compounded.
"I would rather be remembered as a bad artist than a good programmer." What it costs to build something the world depends on — told through the man who did it for eleven years and then had to walk away.
He never left Catania. VMware offered to pay him to stay in Sicily and write code. Twitter flew him to San Francisco to help rebuild their timeline. He went, helped, flew home. The world came to him.
The Tcl prototype was 300 lines. He wrote it to see if the idea worked. The protocol from that throwaway became the Redis v1 protocol. The command names from that throwaway — lpush, rpush — are in production code today. The best designs look like sketches.
LLOOGG — the startup that created Redis — ran 2 billion page views over five years on a $150/month virtual machine. MySQL would have needed a data center. Redis needed a cheap VM. The economics of getting the abstraction right.
