The gold rush metaphor is so overused in venture capital that it has lost most of its analytical force. But the underlying insight — that in periods of rapid technological change, the companies selling picks and shovels to the miners often generate more durable value than the miners themselves — retains real explanatory power. The application layer of the software stack gets the attention: the AI applications, the consumer products, the vertical SaaS solutions. The infrastructure layer — the databases, the orchestration systems, the developer platforms — does the foundational work that makes all of it possible, and it is in the infrastructure layer that some of the most defensible businesses in technology are being built today.
Consider the evidence. Yugabyte, the distributed SQL database company, reached a $1.3 billion valuation in 2022 — backed by investors who understood that the migration of enterprise workloads from monolithic databases to cloud-native, globally distributed architectures was an enduring structural shift, not a temporary trend. CockroachLabs, building a similar distributed SQL architecture with a different set of trade-offs, reached a $5 billion valuation in the same year — a striking proof point that the market was large enough to sustain multiple well-capitalized competitors without either being obviously crowded out. Temporal Technologies, which built an open-source workflow orchestration platform to solve the hard problem of reliable execution in distributed systems, raised at a $120 million valuation in 2022, validating a category — durable execution — that did not have an accepted name three years earlier.
These are not incremental improvements on existing products. They are foundational rewrites of the architectural assumptions that underpin modern software systems. And they share a common characteristic: once a company's engineering organization has built its core systems on one of these platforms, the switching cost is extraordinary. This is the key to understanding why infrastructure software, despite its engineering complexity and often longer sales cycles, produces some of the most defensible business models in technology.
Why Infrastructure Defensibility Is Structural, Not Accidental
The defensibility of infrastructure businesses is not simply a matter of switching costs, though switching costs are real and significant. It is the product of several structural factors that compound over time and that distinguish infrastructure from application-layer software in ways that matter enormously for investors.
The first factor is depth of integration. An infrastructure product that is embedded in the core data layer of an enterprise — a database, a message queue, a workflow orchestration system — is not integrated at the feature level. It is integrated at the architectural level. Replacing it requires not just changing a vendor but re-engineering the systems built on top of it. This is a project that senior engineers estimate in months or years, that finance teams see as high-risk and high-cost, and that procurement organizations are deeply reluctant to initiate unless the incumbent product has failed in a way that cannot be remediated. The switching cost is asymmetric: it is much lower when the customer is first selecting a vendor than it is after they have built their systems on one.
The second factor is the network effects that accumulate in developer-facing infrastructure. When a database, an orchestration system, or a developer platform achieves significant adoption, it generates a surrounding ecosystem — documentation, tutorials, Stack Overflow answers, third-party integrations, hiring pools of engineers who know the system — that makes it progressively easier to use and progressively harder to replace with something unfamiliar. The most successful open-source infrastructure projects have exploited this dynamic deliberately, seeding community adoption before pursuing commercial monetization, and building ecosystems that create value for the commercial product without being paid for directly.
The third factor is the correlation between technical quality and business outcomes in infrastructure. In application-layer software, technical quality is one input into business success among several — the quality of the go-to-market motion, the strength of the brand, the timeliness of the product relative to market demand often matter as much or more. In infrastructure, technical quality is a near-necessary condition for business success, because engineers evaluate infrastructure products with a rigor that they rarely apply to other software categories. An infrastructure product that fails in production — that loses data, introduces latency, or behaves non-deterministically under load — is immediately disqualified, regardless of how compelling its other attributes are. This means that the companies capable of building genuine technical excellence in infrastructure have a much higher probability of building lasting businesses, because their technical differentiation cannot easily be copied by well-funded but less technically capable competitors.
The Distributed Database Renaissance: Yugabyte and CockroachLabs
The distributed database market represents one of the clearest examples of an infrastructure category that emerged from structural necessity rather than venture fashion. The trigger was the inadequacy of traditional relational databases — PostgreSQL, MySQL, Oracle — to support applications that needed to operate across multiple geographic regions with consistent performance, high availability, and ACID transaction guarantees simultaneously. The cloud giants solved this problem for their own internal systems by building custom distributed databases, and then productized those solutions (Amazon Aurora, Google Spanner, Azure Cosmos DB). But the cloud-native distributed database market was not captured by the hyperscalers: it generated independent companies with their own architectural approaches and commercial strategies.
Yugabyte built YugabyteDB as a distributed SQL database that is API-compatible with PostgreSQL — a design decision of considerable commercial importance, because it allowed developers who knew PostgreSQL to adopt YugabyteDB without relearning a new query language or rewriting their application logic. The PostgreSQL compatibility created a dramatically lower barrier to initial adoption, while the distributed architecture provided the capabilities that PostgreSQL alone could not deliver: multi-region active-active deployments, horizontal scalability, and the elimination of single points of failure. The $1.3 billion valuation in 2022 reflected investors' assessment that the TAM for distributed SQL databases was large, that Yugabyte had a technically credible solution, and that the PostgreSQL compatibility was a genuine competitive advantage.
CockroachLabs took a different architectural approach. CockroachDB was built for global horizontal scalability and high availability with automatic data distribution and re-balancing — optimized for the use case where data needs to be distributed across multiple regions or even multiple cloud providers simultaneously. The commercial trajectory validated that there was genuine enterprise demand for these capabilities: CockroachLabs closed contracts with major financial institutions, retailers, and technology companies who needed the combination of relational consistency and global distribution that CockroachDB provided. The $5 billion valuation in 2022 was a strong signal that distributed databases had moved from experimental technology to production-critical infrastructure for a significant portion of the enterprise market.
What the Yugabyte and CockroachLabs stories demonstrate for seed investors is a pattern worth internalizing: technical problems that the hyperscalers solved internally for their own systems often represent enormous opportunities for independent companies. The hyperscalers' internal solutions are not available to companies running on-premises or in hybrid cloud environments; they are not portable across cloud providers; and they come bundled with vendor lock-in that many large enterprises are motivated to avoid. Independent infrastructure companies that solve the same technical problems with open-source foundations, multi-cloud compatibility, and enterprise-grade commercial support can capture substantial portions of markets that the hyperscalers have validated but do not fully own.
Temporal and the Discovery of Durable Execution
Temporal Technologies represents a different kind of infrastructure opportunity — one that did not emerge from a pre-existing well-understood problem category but from a new insight about what software systems need that they have not historically had: reliable, durable execution of complex business logic across distributed systems.
The problem Temporal solves is deceptively simple to state and genuinely difficult to solve. Modern applications frequently need to execute multi-step processes — processes that might take minutes, hours, or days, that depend on external services that can fail or be temporarily unavailable, and that must be guaranteed to complete correctly even in the face of process crashes, network partitions, or cloud provider outages. Prior to Temporal, solving this problem required engineers to build custom state machines, implement their own retry logic, manage their own queues, and handle their own failure cases — a significant amount of infrastructure engineering that had to be reinvented at each company that needed it. Temporal's core innovation was to make the state machine implicit rather than explicit: developers write ordinary code, and Temporal ensures that the code runs correctly to completion regardless of the failures that occur in the underlying infrastructure.
The elegance of the Temporal model — write code as if execution is reliable, and the infrastructure handles the hard parts — attracted developers rapidly, and the open-source adoption was substantial before the commercial offering was fully developed. Temporal was originally created at Uber, where the underlying technology (originally called Cadence) was built to manage the complex workflows involved in ride-sharing operations. When the Temporal founders spun out to build an independent commercial product, they brought both the technical credibility of a production-validated system and a community of developers who had already adopted the open-source version.
The $120 million valuation in the 2022 funding round was modest relative to Yugabyte and CockroachLabs — a reflection of an earlier stage of commercial development rather than a smaller opportunity. The category that Temporal created — durable execution — is now recognized as a genuine infrastructure primitive, and multiple well-funded competitors have emerged, which is typically a sign that investors believe the market is large rather than a sign that the category is overcrowded. For seed investors evaluating infrastructure opportunities, the Temporal story provides a useful template: a category-defining technical insight, validated first in a demanding production environment, with open-source community adoption providing proof of developer value before commercial monetization begins.
The Open-Source Strategy: Distribution Without Enterprise Sales
One of the most important strategic patterns in modern infrastructure investing is the open-source commercial model — building a freely available open-source core product and monetizing through a cloud-hosted managed service, enterprise support agreements, or a commercial version with advanced features. Temporal, Yugabyte, and CockroachLabs all employed variants of this model, and it has become close to the dominant go-to-market strategy for serious infrastructure companies.
The logic is compelling. Open-source distribution gives an infrastructure product access to every developer in the world without requiring an enterprise sales force. Developers who adopt the open-source version in side projects or proof-of-concept implementations become internal champions when they move to production environments — and when they change jobs, they bring their tool preferences with them. The community of open-source users generates documentation, tutorials, integrations, and bug reports that improve the product continuously without incremental cost to the company. And when the company is ready to monetize, it is approaching customers who already understand the product, already trust the team behind it, and already have a stake in its continued development.
The open-source model also provides a powerful signal for investors. A database or infrastructure product that has achieved genuine developer adoption — measured in GitHub stars, download volume, community forum activity, and third-party integrations — has demonstrated product-market fit in the most demanding possible environment: developers evaluating tools for their own use with no sales pressure and no contractual obligation. Developer adoption is a leading indicator of eventual commercial success that is harder to fake than almost any other metric in enterprise software.
What the open-source model requires, however, is that the commercial layer be designed carefully. The history of open-source infrastructure companies is littered with examples of products that achieved extraordinary developer adoption but failed to build sustainable commercial models — either because the open-source version was so complete that customers saw no reason to pay for a commercial version, or because the cloud providers offered managed services based on the open-source code at prices the company could not match. The companies that have navigated this tension most successfully — HashiCorp, Confluent, Databricks among them — did so by offering managed cloud services and enterprise features that created genuine value beyond the open-source core, while maintaining the open-source community as the primary channel for developer adoption.
The AI Adjacency: Infrastructure for Machine Learning Workloads
The emergence of AI as a production workload in enterprise technology is creating a new wave of infrastructure opportunity that sits at the intersection of traditional database and data infrastructure and the specific requirements of machine learning systems. This intersection is one of the areas where Leveiir is paying closest attention today.
The requirements of AI workloads diverge from traditional transactional workloads in ways that create genuine new infrastructure needs. Vector databases — optimized for storing and querying high-dimensional embeddings, which are the fundamental data structure of modern machine learning models — emerged as a distinct product category in 2022 and attracted substantial venture investment very quickly. The rapid rise of Pinecone, Weaviate, Qdrant, and other vector database companies reflected genuine enterprise demand for infrastructure purpose-built for AI retrieval use cases. Feature stores, model registries, experiment tracking systems, and deployment infrastructure for large language models similarly represent infrastructure categories where the existing tools were not designed for the specific requirements of AI workloads.
The pattern here mirrors what happened in the distributed database market a decade earlier: a new category of workloads with technical requirements that existing infrastructure was not designed to meet, generating demand for purpose-built solutions from companies that understand both the technical requirements and the commercial landscape. The speed at which AI infrastructure categories emerged — from concept to well-funded category leader in twelve to eighteen months, in several cases — reflects the urgency of enterprise demand and the willingness of sophisticated investors to back the infrastructure layer before the application layer has fully crystallized.
For seed investors, the AI infrastructure opportunity has some important characteristics that distinguish it from the broader infrastructure category. The evaluation horizon is compressed: the pace of technical change in AI infrastructure means that products can be validated or invalidated by market feedback much faster than traditional infrastructure. The technical barrier is high: building AI infrastructure that performs well at scale requires engineers with both machine learning expertise and systems programming depth — a combination that is rare and expensive. And the competitive landscape is intense: both the hyperscalers and well-funded startups are building aggressively in AI infrastructure, which means that the differentiation required to sustain a position is higher than in many infrastructure categories.
How Leveiir Evaluates Infrastructure Investments
The criteria we apply when evaluating potential infrastructure investments reflect both the specific defensibility characteristics of the category and the particular failure modes we have observed in infrastructure companies that did not achieve their potential.
The first criterion is what we call the depth of the technical problem. Infrastructure investments that succeed over the long term are solving problems that are genuinely hard — problems that require systems-level expertise, that cannot be addressed by adding features to an existing product, and that will remain relevant as the surrounding technology landscape evolves. The problem Temporal solved — reliable distributed execution — is not going away as enterprise systems become more complex; if anything, it is becoming more important. The problem CockroachLabs solved — globally distributed SQL with strong consistency — is not going away as enterprise applications become more global. The hardness of the problem is a feature, not a bug, because it is what sustains the competitive moat over time.
The second criterion is founder depth. In infrastructure, the founding team's technical credentials matter more than in almost any other category, because customers evaluate infrastructure products primarily on technical merit. We look for founders who have built and operated the systems they are now productizing — engineers who understand the failure modes from direct experience, not from reading papers. The most compelling infrastructure founders we have met are people who built the product to solve a problem they encountered in production, not people who identified a market opportunity and decided to build a technical solution to capture it. The distinction is apparent in how founders talk about their products: production-experienced founders have specific, visceral accounts of the failures they needed to prevent; market-opportunity founders have general descriptions of technical problems they have not personally experienced.
The third criterion is the commercial translation path. Open-source adoption is an important signal, but it is not a commercial model. We want to understand how the founding team thinks about the translation from open-source adoption to commercial revenue — specifically, what the commercial tier offers that the open-source version does not, who in the customer organization controls the budget, and what the decision process looks like for the enterprise contracts that will ultimately determine the company's revenue trajectory. Infrastructure companies whose founders have enterprise sales experience — or who have built their team with experienced enterprise sales leadership early — navigate this transition significantly better than those who treat the commercial layer as an afterthought to the technical work.
The fourth criterion is the shape of the competitive landscape. We are not looking for markets with no competition — those rarely exist in infrastructure categories that matter. We are looking for markets where the competitive dynamics favor companies with genuine technical differentiation and open-source community strength over companies with larger sales forces or better marketing budgets. In most infrastructure categories, technical quality eventually wins — but the timeline can be extended by incumbents with large installed bases and long-term contracts. We want to understand how the company we are evaluating is positioned to win on the timelines that matter for our fund economics.
The Decade Ahead: Where Infrastructure Opportunity Is Concentrating
Looking at the infrastructure landscape entering 2025, we see several specific areas where Leveiir believes the opportunity for seed-stage infrastructure investments is particularly strong.
The first is infrastructure for multi-agent AI systems. As enterprises move from deploying single AI models to deploying systems of interacting AI agents — each with its own context, tool access, and decision-making authority — the infrastructure requirements for managing those systems become genuinely complex. Orchestration, state management, observability, and safety enforcement for multi-agent systems are infrastructure problems that do not have mature solutions today. The companies that build the foundational infrastructure for this wave of enterprise AI deployment are likely to occupy positions similar to those of Temporal and Yugabyte in their respective categories.
The second is data infrastructure for regulated industries. Financial services, healthcare, and government sectors are increasingly adopting cloud-native architectures, but they require infrastructure that meets specific compliance, data residency, and audit requirements that general-purpose cloud infrastructure does not always address cleanly. Companies that build infrastructure with compliance-first architectures — databases, pipelines, and orchestration systems that make regulatory compliance a property of the infrastructure rather than a layer built on top — have a structural advantage in these large and underserved markets.
The third is edge infrastructure. The trend toward running computation closer to data sources — at the network edge, in on-premises environments, or on device — is creating demand for infrastructure tools that work effectively in constrained, intermittently-connected, and heterogeneous environments. The assumptions embedded in most current cloud-native infrastructure — that compute is abundant, network connectivity is reliable, and data centers provide a consistent runtime environment — do not hold at the edge. Companies that rebuild these infrastructure primitives for edge environments are addressing a large and growing market that the existing cloud-native toolchain does not serve well.
The investment thesis for B2B SaaS infrastructure is not complicated: the world runs on software, software runs on infrastructure, and the infrastructure layer is structurally more defensible than the application layer. Yugabyte, CockroachLabs, and Temporal validated this thesis with valuations that reflected the genuine scarcity of companies capable of building and distributing infrastructure at the required level of technical quality. The next cohort of infrastructure companies is being built today, often by engineers who have worked at these companies and who are now taking the lessons they learned into new problem spaces. Finding those engineers at the seed stage — before the larger funds have noticed them, when the valuations reflect technical risk that careful evaluation can largely price — is where the most compelling infrastructure investments begin.
At Leveiir, we have spent years building the network and the technical credibility to identify these founders early. Our background as operators in enterprise software gives us a vocabulary that resonates with technical founders who have spent their careers building systems rather than selling them. And our global perspective — with particular depth in the Eastern European technical ecosystem that produced many of the engineers now defining the next generation of infrastructure — gives us access to founders that geographically-constrained funds do not see. Infrastructure investing requires patience, technical depth, and a long view. It is, we believe, among the highest-conviction categories available to seed investors today.