In the autumn of 2013, Paul Dix stopped working on the company he had started and began working on the thing concealed inside it. The company was Errplane, a real-time monitoring service from Y Combinator’s Winter 2013 class. Its customers were not arriving in sufficient numbers. Its infrastructure, however, had acquired a quiet constituency. A few users cared less about Errplane’s polished promise than about the machinery underneath: a way to collect, store and question data whose meaning depended on time.
Dix and cofounder Todd Persen gave the detour five weeks. It was an admirably specific allotment for a possible salvation. They paused the application and pulled its data layer into a standalone open source project. The first version used Go and LevelDB, preserving the shape of an API they had already rebuilt once. Dix arranged talks in New York and put the documentation online. A link reached Hacker News and sat on the front page for most of a day. The project was InfluxDB.
The pivot now sounds preordained because successful companies make excellent editors of their own origins. It was not. Errplane had raised seed money. The team had a product and roughly twenty paying customers. Yet its only alternative idea on the YC application had been “an open source time series database.” The escape hatch had been written down before anyone needed to use it.
Time had been following him
Long before InfluxDB had a name, Dix had met the problem in the financial markets. In 2010 he worked at a New York fintech startup whose pricing engine refreshed predictions every ten seconds across hundreds of thousands of instruments. He built Scala web services over Cassandra, with Redis doing real-time indexing. It was not sold as a time series database. It was simply the infrastructure demanded by facts that kept changing.
His route there had been pleasantly indirect. Dix entered the computer industry in the late 1990s, straight out of high school, and later attended Columbia University, earning a computer science degree. He became part of New York’s Ruby scene, wrote open source libraries and published Service-Oriented Design with Ruby and Rails in 2010. In 2009 he founded the NYC Machine Learning Meetup, years before machine learning became the conversational parsley sprinkled over every technology menu.
Those strands converged inside Errplane. Dix knew service architecture, real-time financial data, machine learning and developer communities. The original product proposed anomaly detection for monitoring systems. To reach the clever part, the team first had to build the unglamorous part: ingestion, storage and queries. Customers pointed, with their wallets, to the plumbing.
“The product isn't going well, but there's something here.”Paul Dix, recalling the 2013 pivot
A year after the first commit, Dix wrote a progress report from a Starbucks in Tokyo. A developer at the Japanese gaming company GREE had invited him to speak about building InfluxDB in Go and was already using it for server and application metrics. Forty-seven people had contributed pull requests. For a project that had not existed twelve months earlier, the trip was a neat proof of open source’s peculiar geography: code leaves home faster than its author does.
Open source was not decorative packaging for the new idea. It was the route into other people’s systems. Dix reasoned that developers would hesitate to build their own products on a closed foundation controlled by a young company, while code they could inspect and run themselves invited experimentation. Talks supplied the introduction; the repository supplied the trust. That pattern later shaped InfluxData’s sales motion. Teams often arrived as customers only after the free software had already proved useful in production. Adoption began with an engineer solving a problem, not a procurement committee admiring a brochure.
The founder changes chairs
InfluxDB became the company’s center of gravity. Errplane became InfluxData. Funding arrived, including an $8.1 million Series A in 2014, and the small technical wager acquired the familiar obligations of a venture-backed business: hiring, boards, sales, customers and the difficult arithmetic of giving software away while paying people to improve it.
Dix did not pretend that arithmetic was elegant. He argued that infrastructure companies needed an open core substantial enough to attract a real community and a commercial layer valuable enough that some users would pay. When licensing choices drew accusations of bait and switch, he acknowledged why people were angry. He also described the alternative as closing the company and hoping someone else might carry the project. Candor does not end an argument, but it makes the disagreement worth having.
Another blunt decision came in 2016. After a three-hour lunch with veteran executive Evan Kaplan, followed by months of planning work and the occasional CrossFit session, Dix asked Kaplan to become CEO. Dix felt spread thin and wanted to return to products and technology. The move surrendered a title and recovered a job. As CTO, he could spend his days on storage, queries, clustering and the long technical future.
This is where Dix’s temperament becomes legible. He appears less interested in defending prior arrangements than in preserving room to work. The company structure could change. The database could change. Even the language in which its core was written could change. Continuity lived in the problem, not the furniture.
Three engines, one recurring question
Rewriting the answer
By 2020, the environment around InfluxDB had shifted. Kubernetes had become ordinary. Object storage had become an economical foundation. Users wanted SQL and analytics across high-cardinality data. The existing engine, shaped for the constraints of 2013, carried limits that a sequence of tasteful renovations could not remove.
Dix announced InfluxDB IOx, the project that would become the core of InfluxDB 3. The new system was written in Rust and assembled around Apache Arrow, DataFusion, Flight and Parquet. Compute could separate from storage. Historical data could live cheaply in object storage. Columnar files could support both compression and broad analytical queries. The old house had good memories; the lot needed different foundations.
Database rewrites are famous for eating calendars. This one took four and a half years to reach the April 2025 general availability of InfluxDB 3 Core and Enterprise. Core offered a permissively licensed, single-process engine focused on recent data. Enterprise added longer historical queries, high availability, stronger security and multi-node operation. Both carried an embedded Python processing engine, allowing data to trigger transformations, alerts and automation near where it landed.
The rebuild also contained reversals. Flux, a query language InfluxData had created for version 2, moved into maintenance while the company focused on SQL and InfluxQL. Early plans for how the open and commercial pieces would divide proved unworkable. Dix documented the changes in long posts, including the awkward bits. An architecture diagram may be neutral; the years spent reaching it rarely are.
“Time series data never stops.”Paul Dix at the InfluxDB 3 launch
The next factory
In July 2026, InfluxDB 3.11 shipped with a new storage system for wide and sparse schemas, faster selective queries and bulk Parquet import and export. Dix called it the largest release since 3.0 and the culmination of roughly a year and a half of work he had led with the database team. For someone whose product records change, there is a certain justice in never being finished.
His attention has also moved one level above the database, toward the way software itself gets made. In 2026 he began writing and speaking about coding agents, quality assurance and what he calls the machine that builds the machine. The question is familiar: if the apparent product becomes cheap to produce, where does the hard and valuable layer move? His answer is drifting toward specifications, test systems, review loops and organizational machinery that can turn generated code into dependable changes.
This does not require the cartoon choice between worshipping automation and refusing it. Dix has tested agents on real side projects, sent work toward production, found the rough edges and, for a spell, returned to coding by hand. The posture resembles his database work: experiment in public, keep what survives contact, replace what does not.
The most revealing phrase in his older writing may be “time to awesome,” his shorthand for how quickly a developer should reach a useful result. It is cheerfully unfashionable, a little 2010s in the best way, and more precise than it first appears. Dix’s career has been spent shortening the distance between raw events and comprehension. Sometimes that meant a friendlier API. Sometimes it meant open sourcing the entire foundation. Sometimes it meant four and a half years of rebuilding.
A time series is a record of values refusing to stay put. Paul Dix built a company around that fact, then behaved as if it applied to companies, tools and founders too. The trick was never to bottle time permanently. It was to build a bottle worth replacing.