As microeconomic concepts go, vertical integration is simple enough to understand: per Investopedia, it’s defined as a “strategy that allows a company to streamline its operations by taking direct ownership of various stages of its production process rather than relying on external contractors or suppliers.” Simple though it may be conceptually, however, it has proven to be much more difficult to evaluate as an approach. As a 2010 paper from a team of Harvard, MIT, University College London and University of Zurich researchers put it, the “economics profession is far from a consensus on the empirical determinants of vertical integration in general.” Which is perhaps not a surprise, given that vertical integration as a strategy seems almost evenly balanced between its costs and benefits. Potential gains in efficiency, for example, may be offset by higher hard and soft costs, more limited tactical flexibility or both. In evaluating the question of whether vertical integration is profitable, then, small wonder that the conclusion of this 1983 Harvard Business Review piece is “Sometimes yes, sometimes no.”
This analysis, and this question, is broadly interesting for the technology landscape, but perhaps nowhere more so than the convergence of the application platform and database markets.
Amazon’s recent step back from its prior direction of travel notwithstanding, the trendline from a broader industry perspective is clear: primitives are going to be with us indefinitely, but will increasingly be complemented by, and in many cases competing with, higher level abstractions.
There are already too many primitives for engineers to deeply understand and manage them all, and more arrive by the day. And even if that were not the case, there is too little upside for the overwhelming majority of organizations to select, implement, integrate, operate and secure every last component or service. Time spent managing enterprise infrastructure minutiae is time not spent building out its own business.
What this means in practice is previously distinct categories of software are increasingly likely to be collapsed, as we’ve speculated about and have subsequently seen with CDNs and general purpose clouds as but one example. Given the fact that most application platforms will require a database and most database platforms will be backing applications, the clear implication is that application platforms should be eyeing database vendors with an eye towards acquisition, and that database vendors should be considering application platforms for the same reason.
The market is driving players at both ends of the spectrum towards vertical integration, in other words.
Not that the concept is new, to be clear: Heroku, for one, has offered a combination of the two for fifteen years, and never quite managed to hit mainstream acceptance. Nor is the concept as straightforward as the kind of vertical integration examples you might see in an economics text book. Car manufacturers acquiring specialized suppliers that provide specialized parts is a straightforward proposal, but an application platform looking to acquire a database would be forced to answer the question of which database? And perhaps more importantly, which type of database, for which workload and for which audience?
But while those are legitimate questions, there are potential answers whether that’s more versatile, trending-back-to-general-purpose database platforms, abstraction layers like GraphQL (there’s a reason players like Hasura or Prisma come up a lot) or some combination of the two.
Regardless of the difficulty, the user demand is evident and accelerating. Developers increasingly want at least the option of platforms with a native and fully integrated database, and if one application platform vendor passes because it’s technically difficult or expensive that’s just the opportunity for the next.
Database vendors, meanwhile, might have equal incentive to contemplate moving up the stack by acquiring application platforms. It seems safe to assume that if developer demands are met and platforms that might have been referred to as PaaS in the past become more popular, the hyperscale cloud players will move to meet that demand. And if we assume, if only for the sake of argument, that they move forward with these higher levels of abstraction, they seem highly likely to be vertically integrated – i.e. composed of entirely native, first party services. Not least because no hyperscale player wants to introduce external dependencies to their own package offering – be those technical, pricing or otherwise. This would leave database vendors competing with integrated, full stack application and database platforms with only the database to offer – a proposition that would be inconvenient in the short term but with the potential to be genuinely problematic in the mid- to longer term.
A $25B database vendor like MongoDB, for example, could look at the declining valuations to some developer infrastructure plays and assess whether the founders and boards of adjacent application platforms were getting cold feet and, if so, might some of the players be obtained more economically today than they could a few quarters ago? Frankly, even if the original valuations stand, many of the relevant players are affordable, at least on paper. Netlify was valued at $2B in mid-November of last year and Vercel at $2.5B six days later. Those are far from trivial expenses, but if convergence continues across the industry a response may well be necessary, and the application platform options are not exactly numerous.
Whether it makes sense for technology vendors broadly to vertically integrate remains, of course, an open question. Or as the HBR authors put it: sometimes yes, sometimes no.
But in the database market, in the not too distant future, it may be less a question, and more of an imperative.
Disclosure: AWS, Hasura, Heroku (Salesforce) and MongoDB are RedMonk customers. Netlify, Prisma and Vercel are not currently customers.
