When I started in web development, the architecture of an application always radiated out from the database. Any application was firmly rooted in its data schema, and the first step was sketching out the tables and relationships that would define how data was organized and retrieved. But that’s where the web was, not where it’s headed. Today, I’m struck by how little developers need to think about the database.
Databases are still at the heart of the modern web, just as servers still dutifully power the expanding array of serverless offerings. But it’s today possible—and common—to the author to deploy rich, interactive web applications without managing database infrastructure or knowing how the data is ultimately stored.
It’s a shift in the making: developing directly against the database became less common with the rise of web frameworks like Rails and the ORM. Even with these abstractions, it was still advisable to understand the schema of tables beneath so you could drop down to SQL to optimize critical queries as you tweaked performance. To know your app, you had to know your database.
The mighty, monolithic database and its role as an oracle—as the only source of truth—is being challenged on two fronts. The first challenge comes from inside each company as more development teams adopt microservice architectures, structuring each service to focus on a single domain complete with its datastore. While companies sometimes try building a microservice stack on top of a monolithic database, this tends to be the worst of both worlds. Individual teams still need to own the data layer.
The second challenge to the central database comes from outside the company: the explosion of API services — the economy of developer-centric offerings powering everything (payment, search, content authoring, artificial intelligence). The productivity lift from instant access to APIs and services makes the benefits of decoupling an application too large to ignore. This requires a shift in thinking from “my database” to “my data,” trading direct access to each table for indirect access via APIs. It’s the right tradeoff, even if data is spread across third-party services.
Monolithic databases were straining under the weight of additional requirements as applications grew. A service like Stripe bundles compute and data behind a payment API, managing, scaling, securing, and optimizing databases for payment processing in ways that would be out of reach to all but the most prominent web teams. New “content APIs”—hosted services like Contentful and Sanity—allow entire teams to author all types of content without managing a CMS or the database behind it.
