Palo Alto, CaliforniaCofounder and coderUpstash since 2021$10M Series ADatabases that scale to zero

Person / Founder / Engineer

Enes Akar Is Making the Database Disappear

After two decades inside distributed systems, the Upstash co-founder has turned an engineer’s irritation with idle infrastructure into a company built for code that appears, runs and vanishes.

Advertisement

The database has always been a needy houseguest. It wants a room before it arrives, money while it sleeps and supervision while everybody else is trying to enjoy the party. Enes Akar has spent the better part of two decades learning its habits. At Upstash, the company he co-founded in 2021, he is attempting the polite eviction: keep the data, lose the ceremony.

The idea sounds almost suspiciously reasonable. A serverless application may wake for a fraction of a second, answer a request and disappear. The database behind it should be able to behave with similar thrift. It should scale down when nobody is calling, respond from wherever the user happens to be and charge for work performed rather than furniture left plugged in.

Akar’s version of the pitch is economical because he has already lived through the longer explanation. His career began in Java development at Alcatel-Lucent, moved through iLab Holding and Ericsson, and then settled into the distributed-systems company Hazelcast. He joined Hazelcast as an early developer in 2011, led engineering, and later became CTO of Hazelcast Cloud. After a stint as an engineering leader at Confluent in 2020, he started Upstash with Mehmet Dogan and Bilal Kuz.

85KDevelopers reported by early 2024
$1MAnnual recurring revenue reported in 2024
$11.9MTotal publicly announced funding

A bill is a product decision

Cloud computing promised that companies would rent rather than own their machines. But renting introduced its own small absurdity: a developer could spend hundreds of dollars each month before meaningful data had moved at all. Upstash began with Redis and Kafka offered on a consumption model. The customer would pay when requests arrived. The infrastructure would recede when they did not.

“Consumption pricing is our biggest differentiation in the market because it removes barriers for developers.”Enes Akar, 2024

That sentence carries more product thinking than its accountant’s clothing suggests. Pricing decides who gets to experiment. A standing bill asks for confidence in advance; metered use permits uncertainty. The college student, the side-project tinkerer and the startup without customers can all begin without renting a mostly empty banquet hall.

It also forces an architectural promise. “Pay for what you use” is only attractive if the service can wake quickly, remain available and avoid turning every cold start into an apology. The commercial model and the technical system become roommates. Each has to tolerate the other.

The investor, the no and the curry

By June 2023, Upstash was not shopping for a new round. Andreessen Horowitz approached Akar anyway. He initially preferred to keep building independently. He did, however, agree to a conversation over Indian food in downtown Palo Alto. The restaurant, he later joked, was persuasive enough to justify the meeting.

Dinner did not produce an instant conversion. What caught his attention was the possibility of accepting capital without immediately creating a board. Even then, he said no. Upstash still had money, the product still felt early and Akar valued room to maneuver. This was not the theatrical rejection of venture capital that founders sometimes polish into folklore. It was a practical judgment about timing.

A few months later, the timing looked different. Akar was visiting Eskişehir, his hometown in Turkey, while generative AI was turning data-hungry applications from novelty into category. He called the investors back. Negotiations began, and the deal closed about a month later. In February 2024, Upstash announced a $10 million Series A led by Andreessen Horowitz, alongside a vector database aimed at AI applications.

Enes Akar pictured in the Serverless Data and Upstash speaker artwork
Portrait in a distributed system: Akar in the artwork for his “Serverless Data and Upstash” talk. Even the headshot has edge nodes.

The anecdote is amusing because it refuses the usual mythology. There was no breathless pitch marathon and no founder pretending to have known the future all along. There was an email, a meal, a considered refusal and then a mind changed by fresh evidence. The useful trait was not stubbornness. It was the ability to distinguish independence from immobility.

A career in making machinery quieter

Akar studied computer engineering at Boğaziçi University from 2001 to 2005, then completed an MBA there in 2007. The combination now looks tidy: understand the machine, then understand the bill. His actual career was less symmetrical. It ran through telecom software, in-memory data grids, streaming systems and managed cloud services before arriving at a product that folds all of those lessons into a browser-friendly console and an API.

Java, telecom and enterprise software
Developer to engineering leader at Hazelcast
Engineering leader at Confluent
Co-founds Upstash
Vector, Workflow, Context7, Box and Redis Search

His public biography on X and GitHub compresses the executive title into something more revealing: “cofounder and coder.” Akar writes tutorials, publishes benchmarks and announces products in the vocabulary of someone who expects readers to try them. The subjects have moved from Redis at the edge and Kafka pipelines to semantic caching, workflows, coding agents and documentation retrieval. The habit has not. Build a tool, explain the friction, show the code.

Upstash’s geography tells a parallel story. The company is based in California, while many members of its engineering team have worked from Turkey. By the 2024 Series A, Akar and chief operating officer Melek Pelen Esin were both in Silicon Valley. Esin was a longtime friend with experience at McKinsey, Facebook and MIT. She took the business side of the house while Akar ran engineering. The division was unusually legible: one leader translating the company outward, the other keeping a hand near the machinery.

The founding group itself had the texture of an engineering team rather than a casting call. Akar, Dogan and Kuz described themselves as developers who had endured high latency, muddled setup and excess configuration. Their answer was not a lifestyle brand draped over a database. It was a checklist of jobs the database ought to perform without being asked: high availability, backups and routine updates. The origin story is therefore less about revelation than accumulated annoyance. Years spent close to infrastructure had given them an exact inventory of what to remove.

The Akar product filter

  1. Find infrastructure developers need but resent maintaining.
  2. Make it reachable from serverless and edge runtimes.
  3. Let cost follow use, including the possibility of zero.
  4. Teach with working examples, not architectural weather reports.

From data for apps to context for agents

Upstash did not preserve every original product. Its serverless Kafka service was eventually deprecated as the team concentrated on QStash messaging and Workflow. The willingness to retire a recognizable category is part of the same discipline as scaling to zero: idle product surface is still idle infrastructure, only it occupies a roadmap instead of a server rack.

The company’s newer work follows developers toward AI. Upstash Vector gave applications a place to store and retrieve embeddings. Context7, introduced in 2025, addresses a more peculiar modern failure: coding models can produce confident answers from stale library documentation. Context7 supplies current, version-aware documentation to AI coding tools. In Akar’s telling, it can also investigate gaps by reading source code and retain useful answers for the next request.

By 2026, his writing had widened again. He introduced Upstash Box as a computer that software agents can use, described enterprise capabilities for Context7 and announced general availability for Redis Search. These products do not make Upstash a different story. They enlarge the original one. An application once needed a database it did not want to manage. An agent now needs documentation, a queue, durable workflows and sometimes an entire computer it should not have to provision.

“As founders who also happen to be developers, we’ve felt the frustration of using tools that offer a poor developer experience.”Enes Akar, writing with the Upstash team

There is an unfashionable steadiness to that complaint. Developer experience can sound decorative, as though someone is choosing the nicer upholstery for a command line. Akar treats it as the product itself. Latency, setup, pricing, APIs and documentation are not separate departments in the user’s mind. They are one continuous encounter with the machine.

The pleasure of useful absence

Infrastructure founders face a comic problem. If the product works, the customer may hardly notice it. Nobody gathers friends to admire a queue that delivered each message exactly once. No wedding toast thanks the cache. Reliability earns its applause in silence.

Akar appears comfortable with that arrangement. His aspiration has remained concrete: reduce the distance between an idea and a running application. Upstash manages replicas, backups, updates and availability so developers can spend their attention elsewhere. The company sells serious machinery by promising not to make a performance of it.

The career behind that promise matters. A person can only make a distributed system look simple after learning all the ways it refuses to be. Akar spent years inside the difficult parts - telecom networks, in-memory grids, streaming platforms and managed clouds. His current work is not an escape from complexity. It is complexity folded, labeled and put away before the guest arrives.

That may be the most useful thing to steal from his story. The next good infrastructure company may not need a grander machine. It may need a smaller obligation. Remove the server to provision, the cluster to babysit, the minimum bill to justify, the documentation tab to distrust. What remains is not magic. It is simply the part the customer came to do.