Arjun Narayan and the virtue of doing the hard part once

Arjun Narayan’s first programs had to work their way downstairs. At a summer programming bootcamp in Bangalore, he wrote code with pen and paper. An instructor reviewed it. Only then could he type it into one of the few computers in the basement. His family could not afford a computer at home. Access to a machine was something you earned, one handwritten program at a time.

His explanation for being there is considerably less solemn than the usual founder origin story. He had been a nuisance at home; his parents needed him out of the house. The arrangement gave them some peace and gave him an introduction to programming. One suspects the instructor received the more demanding end of the bargain.

Years later, Narayan would help build a database company concerned with a different kind of unnecessary waiting. Materialize keeps the results of queries updated as data changes, rather than making users wait for the whole calculation to begin again. The childhood episode and the company are separated by an ocean, a liberal arts education, a doctorate and an engineering job. Still, both involve deciding what work should happen before someone reaches the computer.

Today he is a Venture Partner at Amplify Partners, having been Materialize’s founding CEO. The titles suggest a tidy progression. His own account contains more detours: a prospective physicist, an economics student, a researcher who did not want an academic career, and a founder who discovered he liked helping other founders.

The useful detour through everything else

Narayan grew up in Bangalore before its present identity as a technology centre had taken hold. He wanted to become a theoretical physicist. For high school, a scholarship took him to a boarding school near Bombay, an opportunity he pursued after a friend encouraged him to apply. Seeing the campus widened his sense of what an education could contain.

At Williams College in Massachusetts, he sought room to explore. History and economics were possibilities. Computer science entered the mix and held his attention. He graduated with a B.A. in computer science and economics, a combination that would later make a certain amount of sense for someone whose working life would span algorithms, companies and investment decisions.

Breadth left him wanting depth. At the University of Pennsylvania, he pursued a Ph.D. in computer science, studying distributed systems and differential privacy. His research brought him into contact with theorem provers, type systems, compilers and databases. He describes the doctorate as a rewarding education even though he quickly realised that becoming an academic was not his goal.

One glimpse of that work appears in a 2014 paper co-authored with Antonis Papadimitriou and Andreas Haeberlen. It examined whether federated systems could help detect systemic threats, using financial institutions as an example. The problem joined computation to the awkward fact that organisations may need a collective answer without wanting to reveal everything to one another. Even in research, the computer had to accommodate the people around it.

A research paper becomes a career decision

In 2012, Google’s Spanner paper caught Narayan’s attention. He was drawn to the possibility that distributed systems could offer stronger, more complete database behaviour instead of handing their complications to users. That conviction helped take him to Cockroach Labs, where he worked on SQL query execution and performance engineering.

The decision also produced an unusually direct negotiation. He asked to receive his compensation entirely in equity. The request was declined. His then-girlfriend, now his wife, had a job at Google that made such a proposal financially conceivable. It is a revealing detail: conviction can sound wonderfully abstract until someone asks payroll to implement it.

Cockroach Labs also supplied relationships that would matter later. Narayan worked there alongside Nikhil Benesch and encountered Nate Stewart, who led product. Meanwhile, another research project kept occupying his attention: Timely Dataflow, associated with Frank McSherry’s work at Microsoft Research. Narayan spent years encouraging McSherry to commercialise the technology.

The eventual pitch became more concrete than a general suggestion that excellent research deserved a company. Put a familiar SQL interface over the computation engine. Give developers a way to use the machinery without first becoming experts in the machinery. The company took shape as Timely Data before becoming Materialize, founded in 2019.

An answer that stays ready

To understand the attraction, imagine repeatedly checking a parcel’s location. You want to know whether it has moved. A system that recalculates the answer from scratch every time you refresh can spend effort rediscovering what it already knew. A maintained view instead changes when relevant underlying information changes. The answer is kept ready for the next person who asks.

That example, which Narayan has used when explaining materialized views, makes the name Materialize less mysterious. The company took an established database idea and built around maintaining results continuously. Underneath sits dataflow technology; above it sits SQL, a language already woven into the working habits of data teams.

In a 2020 Carnegie Mellon database seminar, Narayan described the engineering consequences. Plans must be efficient both to compute initially and to maintain as new data arrives. Work can be related to the changes flowing through the system rather than simply to how often people inspect the results. That is an architectural choice, with its own difficult implementation problems.

His defence of SQL has a social dimension as well as a technical one. Businesses have accumulated queries, tools and practices over years. Asking them to discard all of that is an expensive opening line. A new engine that speaks a familiar language gives people a way to benefit from research while preserving some of the knowledge they already possess.

By September 2021, Materialize had announced a $60 million Series C led by Redpoint, taking its total funding above $100 million. Those figures belong to the company, rather than to Narayan’s personal finances. They also give a sense of the resources required to turn a database idea into something organisations can rely on. A convincing diagram is only the beginning.

The comedy of keeping your answers straight

Narayan’s writing is often where the human cost of technical decisions comes into focus. His 2018 essay on computational complexity argues that questions about what can be computed deserve philosophical attention. It ranges from cryptography to possible computational worlds. The prospective physicist had found another route to questions about the limits of the universe.

Closer to the daily work of software teams, his June 2024 essay about database isolation borrows the predicament of a liar. Once different people have been told incompatible things, keeping every story straight becomes a job of its own. Weak isolation can impose a comparable burden on programmers trying to reason about interacting operations.

The joke has a point. If the database supplies weaker guarantees, developers may need to consider more of the surrounding system each time they change a query. The expense includes meetings, investigations and hours spent reasoning about possible interactions. His argument is that stronger guarantees can move that burden into the database, where it can be handled systematically.

A 2023 essay co-written with Andy Hattemer applies similar scrutiny to cloud data warehouses. A tool suited to exploring historical data can struggle when pressed into continuously serving operational decisions. Their distinction is concrete: an analysis can benefit from a stable dataset, while an operational application may need the latest state. A sensible prototype can become an awkward production dependency.

There is an appealing lack of romance in this way of looking at software. The important question is often who inherits the chores. Someone must maintain the results, reconcile the answers and understand the consequences. Narayan’s technical arguments repeatedly ask whether the infrastructure can shoulder more of that work before a user or programmer has to.

“Developers want to hear the ground truth”Arjun Narayan, 2021

Knowing when to hand over the chair

On April 8, 2024, Materialize announced Nate Stewart as CEO. Narayan moved to VP of Engineering and remained on the board. Stewart had already served as an independent director; their relationship went back to Cockroach Labs. The handover brought a familiar colleague into the operating role.

Narayan described returning to engineering as a return to the early days, when much of his CEO work had involved engineering anyway. His stated contribution would be growing and leading the team alongside his co-founders’ technical vision. There is useful precision in that description. A founder’s relationship with a company can change shape without erasing the work that came before.

In February 2025, Amplify announced him as its newest Venture Partner. The connection had begun years earlier, after Spencer Kimball introduced him to the firm in November 2018. Amplify had considered Materialize and ultimately did not invest. The relationship continued nonetheless, eventually including shared investments in companies such as Hightouch and Modal.

That history is a useful corrective to the idea that every worthwhile business conversation must end in an immediate transaction. An investment that did not happen became a relationship that did. When Narayan later raised the possibility of working in venture capital, the firm already knew how he approached research, product and company building.

The work on the other side of the table

Narayan had begun angel investing during his Materialize years and found that he enjoyed helping founders more than he had expected. At Amplify, his focus is technical founders. His own description of the work includes an important reservation: outside advice can cause harm as well as help. Having an opinion is much easier than understanding the situation in which someone must act on it.

He had made a related argument while running Materialize. A useful peer or adviser can help a startup anticipate the problems coming several months down the road. His analogy was a relay runner beginning to move before receiving the baton. Experience is valuable when it gives someone else a little more time to prepare.

For all the database terminology, there is room for a less vocational obsession. Asked about the Roman Empire, he specifies a preference for the late Republic. Apparently even historical small talk benefits from choosing the correct version. The distinction suits a writer willing to spend pages explaining why superficially similar database guarantees produce very different lives for programmers.

From handwritten programs to maintained queries to conversations with founders, Narayan’s career has involved repeated negotiations over effort. What must be understood? What can be prepared in advance? What should the next person be spared? His work now places those questions beside people building companies of their own. The classroom computer is a long way behind him. The value of making someone else’s turn at the keyboard more useful remains easy to recognise.