Infra Breakdown: Databases
The Layer Every App Is Built On- and Where It's Headed Next
Every software company is, at some capacity, a database company.
Applications change. Frameworks change. Cloud providers come and go. But every product ultimately depends on a system that stores, retrieves, and serves data. Whether you’re a two-person startup or a F500 enterprise, building a consumer app or a defense system, somewhere in the stack there is a database.
And in many cases, it’s the piece of infrastructure that becomes most important and most painful as you scale.
For most of computing history, databases were viewed as plumbing - critical, but largely solved. Enterprises bought Oracle. Startups deployed MySQL. The goal was simple: set it up, keep it running, and avoid touching it whenever possible.
Then three platform shifts reshaped the market.
First, data exploded. Mobile applications, SaaS software, and billions of connected devices dramatically increased the amount of information software needed to store and process. Databases built for the previous era began to show their limits.
Second, the cloud turned infrastructure into software. Instead of buying servers, companies rented compute on demand. A market long dominated by Oracle, IBM, and SAP opened up to a new generation of cloud-native database companies, each optimizing for a different combination of scale, performance, simplicity, and cost.
Third, AI introduced entirely new workloads. Training models requires infrastructure capable of processing massive datasets. Running them in production requires semantic search, low-latency retrieval, vector storage, and entirely new data architectures. AI created requirements that much of the existing database stack was never designed to handle.
Underneath these shifts is a quieter trend that may prove even more important: databases have become developer platforms.
A decade ago, standing up a production-grade database required infrastructure expertise, configuration, and operational overhead. Today a developer can provision a managed database in minutes with authentication, storage, APIs, observability, and scaling built in.
The result is a dramatic compression in the distance between idea and product. Small teams can build software that previously required entire engineering organizations. Internal tools that once took months now take days. AI coding tools can generate applications and deploy them directly onto modern database platforms.
This evolution matters because databases sit at the center of every major trend in software: cloud computing, open source, developer tools, data infrastructure, and now AI.
This breakdown is a tour through eight eras of database evolution, each emerging to solve a limitation created by the one before it. By the end, the modern infrastructure stack should feel less like a collection of buzzwords and more like what it actually is: forty years of the industry debating how to store information reliably, retrieve it efficiently, and make it accessible to the people and systems that need it.
A debate that AI has made dramatically more important, and one that remains far from settled.
What Is a Database?
A database is a system for storing, retrieving, and managing information.
Every application you use depends on one. When you log in, a database verifies your credentials. When you make a purchase, a database records the transaction. When you receive a recommendation, a database is queried to determine what’s most relevant to you.
At its core, every database has two jobs:
Write data reliably.
Read data back quickly.
Everything else is an optimization around those two objectives.
The Fundamental Jobs of a Database
Most of database history is really the story of one problem: transactional workloads and analytical workloads want fundamentally different architectures.
OLTP (Online Transaction Processing)
OLTP databases power live applications. They handle individual reads and writes in milliseconds and prioritize speed, consistency, and availability.
Examples include:
A user logging in
A payment being processed
Inventory updating after a purchase
The defining characteristic is simple: a very large number of small transactions where correctness matters.
OLAP (Online Analytical Processing)
OLAP databases answer business questions. They scan and aggregate large amounts of historical data to generate insights.
Examples include:
Revenue by region last quarter
Product engagement trends
Customer churn over the past year
The defining characteristic is the opposite of OLTP: fewer queries, but significantly larger and more computationally intensive ones.
This distinction matters because the architectures that excel at OLTP often perform poorly at OLAP, and vice versa. Storage formats, indexing strategies, compute architectures, and optimization techniques are frequently designed around one workload at the expense of the other.
For most of computing history, companies solved this problem by running two separate systems: an operational database for applications and an analytical database for reporting. Data was continuously moved between them through pipelines and ETL processes.
The tension between those two worlds, and the industry’s repeated attempts to unify them, is the engine behind nearly every major database innovation that follows.
The Evolution of Databases
Each era of database innovation emerged in response to a constraint created by the previous one. Some optimized for consistency. Others optimized for scale, performance, developer experience, or analytical power.
Yet nearly all of them revolved around the same unresolved question:
Can a single system serve both operational and analytical workloads, or will those worlds remain separate?
The history of databases is, in many ways, the history of that debate.
Supabase: Building the Backend for AI-Native Apps
If PostgreSQL won the database wars, Supabase is trying to win the platform layer built on top of it.
PostgreSQL (a.k.a. “Postgres”) is one of the world’s most widely used open-source databases. As mentioned, at the core, a database stores and organizes application data - e.g., user accounts, transactions, product catalogs, chat messages. Over the past decade, Postgres has become the default choice for many modern software teams because of its reliability, flexibility, and large ecosystem of extensions.
Supabase started by making Postgres easier to deploy and manage in the cloud. Rather than forcing developers to assemble dozens of separate services around a database, it packaged the common backend components most applications need into a single platform.
Supabase started as a managed Postgres offering and has expanded into a full backend platform that includes authentication, storage, real-time subscriptions, edge functions, autogenerated APIs, and native vector search through pgvector. What we’re hearing from developers is that they increasingly want a complete backend, not just a database —> a single platform that handles the most common application requirements out of the box.
The company sits at the intersection of two powerful trends: open-source infrastructure and AI-assisted software development. Many AI coding tools and app generators now deploy directly onto Supabase by default, making it a natural backend for the growing population of developers building with AI. Unlike Firebase, which relies on proprietary abstractions and a NoSQL data model, Supabase is built directly on PostgreSQL. Developers get the benefits of a managed platform while retaining the ability to self-host, migrate, or access the underlying database whenever they choose.
In many ways, Supabase is doing for Postgres what Shopify did for commerce: taking a powerful underlying system and wrapping it with the tools, workflows, and developer experience needed to build production applications quickly. The database remains the foundation, but the value increasingly comes from the platform layered on top.
As Supabase scales following its recent funding round at an $10B pre-money valuation, the central question is whether it can preserve the simplicity that fueled its adoption while supporting increasingly complex production workloads. PostgreSQL remains one of the most trusted and widely deployed databases in the world, but enterprise-scale applications introduce challenges around global replication, connection pooling, multi-region deployments, and horizontal scaling.
Curious to see how Supabase evolves its architecture to handle sharding, distributed workloads, and the growing demands of AI-native applications. As AI-generated software matures from prototypes into mission-critical systems, developers will need infrastructure that combines ease of use with enterprise-grade reliability. If Supabase can navigate that transition while maintaining its open-source ethos and developer-first experience, it has a credible path to becoming the default backend platform for the next generation of software development.
All of that said, one of the reasons I’ve been so excited to follow Supabase is the team behind it. Paul Copplestone has been one of the most thoughtful, developer-first founders I’ve met. His relentless focus on open source, product quality, and empowering developers has been a major driver of the company’s success. I’m excited to see what he and the broader Supabase team continue to build in the years ahead.