Ovais Tariq and the art of making storage uneventful

Ovais Tariq has a useful habit for someone entrusted with other people’s data: he distrusts the work of Ovais Tariq. Asked about bad code that had reached production, he included his own. Give it a year, he said, and he could look back at something he had written and wonder how it had ever been allowed out. It is a rather inconvenient disposition for a victory lap. For a storage engineer, it has its uses.

He also calls himself a perfectionist. The interesting part is where he draws the boundary around perfection. Tariq helped build databases at Uber. At Tigris Data, the company he co-founded with Himank Chaudhary and Yevgeniy Firsov, he chose to build on an existing database, FoundationDB. Experience had made him selective about which hard problems deserved another attempt.

His career offers a close look at a particular kind of ambition: making elaborate machinery feel uneventful to the person using it. The machinery has changed, from MySQL deployments to Uber’s internal storage platform to a global object store. The person at the other end still wants roughly the same thing. Save my work. Bring it back. Please spare me the expedition.

A career in the things people notice when they break

Tariq was born in Karachi and studied computer science at the University of Karachi. His path into infrastructure eventually took him through Percona and Lithium, before nearly six years at Uber. These are useful coordinates for understanding his work. He came to founding a company after spending years inside the systems that applications depend on.

His personal blog preserves the texture of that earlier career. A 2014 post warned about MySQL replication bugs that complicated upgrades. Another examined corruption affecting large binary objects in older MySQL versions. In 2015, he published an update to a Chef multipath cookbook. In 2016, he shared slides from a talk about monitoring MySQL at scale.

There is little glamour in a replication bug, unless you have one. Then a precise explanation from someone who has dealt with it becomes unusually attractive reading. Those posts show Tariq doing the patient, public work of infrastructure engineering: describing a failure, explaining its conditions, and leaving something useful for the next person who encounters it.

Even the title of his blog pairs technology with leadership. That pairing would become central at Uber, where his responsibilities expanded beyond an individual system to the platform other engineers used to build the business.

Uber was the rehearsal with paying passengers

At Uber, Tariq led storage work serving internal developers. His team supplied managed database, blob storage, and caching capabilities. Engineers building an application could consume those services without taking on every operational task themselves. Backups, availability, and the work of running the machinery belonged behind the interface.

That distinction matters. The rider waiting for a car never sees a storage platform. Neither should the developer building a feature have to become its full-time custodian. Tariq’s job sat between those two expectations, turning a large engineering organization’s accumulated expertise into something colleagues could use.

He worked with Chaudhary on Docstore, Uber’s distributed database, and the pair discussed it publicly while still at the company in 2021. Tariq has described bringing Uber’s distributed document database into production as one of his favorite professional experiences. It was a chance to take a system beyond an architectural argument and make it carry real work.

The relationship with his future co-founders grew out of that shared work. They had already dealt with the practical consequences of global storage together. When they founded Tigris in November 2021, they brought a working history as well as a product idea. There are advantages to starting a company with people whose architectural opinions you have already had to live with.

The first Tigris had a different job

In 2022, Tariq was describing Tigris as an open-source data platform for real-time applications. The aim was to bring capabilities together so developers would spend less time connecting separate systems and moving data between them. Database operations, search, and streams belonged in a more coherent experience.

His language was practical. He wanted programmers to work with familiar languages and constructs. He wanted operational concerns handled without turning the product into an opaque box. A technically elegant system still had to make sense to the developer trying to ship an application on a deadline.

By February 2024, Tigris had launched a globally available, S3-compatible object storage service, with backing from Andreessen Horowitz. The product emphasis had changed. Instead of asking customers to adopt a new database experience, Tigris offered a familiar storage interface with different behavior underneath it.

Martin Casado, the a16z investor, described the gap that made this appealing: developers could move their applications to newer hosting platforms while their storage remained attached to the traditional clouds. Tigris was addressing that remaining dependency. Tariq’s concern with reducing a developer’s operational burden survived the change in product.

Keep the bucket. Lose the geography homework.

Object storage sounds more mysterious than its basic interface. Put a named piece of data into a bucket. Retrieve it. List what is there. Delete it when appropriate. The simplicity is part of the appeal. The awkward questions begin when an application needs that data in several places.

Tigris makes the bucket global. Its routing, caching, and replication systems work to place data where it is being accessed. Developers can use the S3 tools they already know while delegating more of the placement problem to the service. For Tariq, the interface is a way to make a complicated system approachable.

FoundationDB handles the metadata at the center of that system. This is the accounting that keeps track of objects and the information needed to serve them. Chaudhary’s 2026 technical explanation describes independently scalable gateways, caches, metadata clusters, storage backends, and background workers. A simple bucket has a substantial organization working beneath it.

Tariq had argued for this kind of reuse years earlier. His 2022 essay about FoundationDB asked why new database projects repeatedly rebuilt low-level machinery. Concurrency, consistency, faults, and balancing load could consume the time a team needed for the features its users actually cared about. His decision to reuse a foundation was an engineering choice about where to spend attention.

Eventually, the cloud needs a screwdriver

In October 2025, Tariq announced a $25 million Series A led by Spark Capital, with continued backing from a16z. The funding supported a business taking on physical infrastructure as well as software. Tigris was deploying its own hardware in data centers.

That decision puts a different weight on the founder’s promises. Running storage involves capacity, drives, networking, and the possibility that hardware will fail. A pleasing API does not relieve the operator of those responsibilities. It merely makes them easier for a customer to overlook when everything is working.

His conversation with Casado in November 2025 went into the details: preparing racks, planning capacity, handling durability, and dividing work between infrastructure and distributed systems teams. For a founder whose product lives behind an endpoint, Tariq spends a fair amount of time discussing the things that must be shipped, installed, and powered.

The emerging AI market gives that work an immediate purpose. Training and inference can happen across different providers and locations. Tigris’s bet is that storage should accommodate those choices. Customers named in Tariq’s funding announcement included fal, KREA, and Hedra, alongside developer infrastructure companies Fly.io and Beam.

Strong opinions, with room for a rewrite

Tariq’s public persona is unusually consistent with the old blog. On X, he advertises strong opinions about infrastructure. The subjects are frequently specific: database choices, object storage, caching, and the decisions made by the team. He remains close enough to the engineering to discuss what changed and why.

In September 2026, Tigris explained a change to its background processing: asynchronous tasks were moving to Kafka after the team encountered limits with its FoundationDB-based queue. Tariq clarified that FoundationDB still held the metadata and remained central to replication commits. The revision was targeted rather than a wholesale abandonment of the design.

It is a revealing continuation of the earlier argument about using existing tools. A decision can be useful and still reach a limit. The work is to identify that limit accurately. For someone who can revisit his own code with suspicion, a public account of an architectural adjustment seems entirely in character.

There is a less technical glimpse of him, too. Asked about favorite films in 2022, he chose Christopher Nolan’s Dark Knight films and singled out Heath Ledger. He said the films moved him. The engineer willing to scrutinize old production code can also surrender to a performance. Even a perfectionist is allowed an evening off.

“We want to give builders their freedom back.”

Ovais Tariq

The freedom he wants to sell

Tariq’s stated ambition is to give developers more freedom over where their applications run. That includes reducing the friction of moving data between providers. It also means taking responsibility for the operational work that makes those choices practical, rather than handing customers another set of systems to assemble.

His story runs from explaining MySQL failures to leading storage teams, then to founding a company willing to operate the hardware behind its software. The common concern is remarkably concrete: what does another engineer need in order to get useful work done? Tariq keeps changing the machinery beneath that question. The customer, ideally, gets to think about something else.