When a customer pays for an order, the database must remember the payment without selling the same final item twice. When an AI agent resumes a task, it needs a reliable record of what happened and what it may do next. Databases provide this durable application state. Their commercial value comes from making correctness and availability routine, even when machines fail or demand surges.
The investment question
The investment question is whether a database supplier can turn developer adoption into enduring production revenue. Download counts, free projects and experimental AI applications are useful signals of interest. They become economically meaningful when applications retain users, store important information and pay for dependable operations.
Our view is that the strongest businesses combine developer convenience with operational trust. Switching costs grow when application logic, data models, security controls and recovery procedures depend on a platform. However, established databases face pressure from open-source alternatives, hyperscaler services and customers who consolidate several specialist databases into one sufficiently capable product.
How databases work
An operational database reads and updates application records. Relational systems organise information into tables and support relationships and constraints. Document databases store flexible document structures. Key-value, graph and time-series systems optimise different access patterns. These categories overlap: a relational database can store documents, and a document platform can offer transactions and search.
Transactions define which changes succeed together, while isolation governs interactions between concurrent operations. Stronger guarantees can simplify application correctness but introduce coordination or retries. PostgreSQL’s transaction documentation makes this distinction explicit. A benchmark that omits the required isolation level, durability or failure behaviour can compare fundamentally different services.
Indexes speed selected reads but consume storage and add work to writes. Replication creates additional copies for resilience or read capacity; it does not replace tested backups. Sharding distributes data across machines, introducing decisions about keys, joins and cross-shard operations. The right architecture depends on latency, growth, recovery needs and transaction patterns, rather than a universal ranking of database technologies.
Market structure and competitive advantage
| Supplier model | Customer proposition | Commercial constraint |
|---|---|---|
| Established proprietary platforms | Mature features and operational familiarity | Migration to cheaper or more flexible alternatives |
| Managed open-source databases | Familiar interfaces with outsourced operations | Multiple providers can offer related technology |
| Independent cloud platforms | Developer experience and differentiated data services | Cloud infrastructure costs and distribution competition |
| Distributed database specialists | Resilience and scale across locations | Coordination complexity and demanding workload economics |
Oracle and Microsoft have extensive enterprise database franchises. PostgreSQL and MySQL support broad ecosystems of hosting, tooling and expertise. MongoDB competes through its document-oriented platform and managed Atlas service. AWS, Microsoft Azure and Google Cloud sell database services alongside the infrastructure and applications that generate demand.
The moat is often organisational as well as technical. A company must trust upgrades, incident response, access controls and recovery under stress. Familiar query languages reduce one migration barrier, but compatibility does not guarantee identical extensions, transaction behaviour or operating procedures. Customers assess the cost of changing the whole application environment.
Economics: measure the application, not just the instance
Database spending can include compute, storage, input/output operations, replicas, backups, networking and support. Managed services may reduce administration while increasing the visible provider bill. The comparison should include engineering time, downtime exposure and the resources required to meet the same service level.
Consider an illustrative application spending £10,000 monthly to serve ten million successful transactions: its database cost is 0.1 pence per transaction. If optimisation cuts spending to £8,000 while transactions rise to twelve million, cost falls to roughly 0.067 pence. Usage grew while supplier revenue declined. This is arithmetic, not a forecast, and excludes the rest of the application stack.
Conversely, redundant capacity can increase revenue without improving useful throughput. High availability may justify that expense, but analysts should understand what customers are buying. Gross margin depends on infrastructure procurement, utilisation, software efficiency, support intensity and the balance between self-managed software and hosted services.
Consumption models expose suppliers to customer optimisation. Commitments can improve predictability but do not establish permanent growth. Retention is more informative when combined with workload additions, production usage and the distribution of customer spending, rather than interpreted as a standalone measure of product indispensability.
AI and hyperscalers: durable state and retrieval
AI applications create database demand through user sessions, conversation history, tool results, permissions and agent state. An agent executing a business workflow still needs reliable transactions around payments, inventory or approvals. A language model’s ability to generate a plausible response does not provide those guarantees.
Retrieval adds another workload. Embeddings represent content numerically so applications can search for related material. The pgvector project brings exact and approximate vector similarity search to Postgres. Approximate indexes trade some recall for speed; practical evaluation must also test metadata filtering, update freshness and performance at the required concurrency.
Hyperscalers can place databases close to model endpoints and application compute, simplify billing and integrate identity. Independents can compete through developer preference, portability and specialised capabilities. Yet a database running across several clouds is not automatically easy to move between them: transfer costs, operational dependencies and application-specific behaviour still matter.
Current market debates — September 2026
The first debate is whether AI changes database growth materially or mainly changes product positioning. MongoDB’s second-quarter fiscal 2027 results, released on 1 September 2026, reported total revenue growth of 30% and approximately 29% Atlas growth. These are company-wide measures, not a separately disclosed estimate of incremental AI revenue. The investment case needs evidence that AI applications become substantial recurring workloads.
The second debate is consolidation versus specialist retrieval. Keeping vectors beside operational records can simplify permissions, freshness and development. Dedicated retrieval systems may still win demanding workloads through scale, latency, hybrid search or operational features. The relevant comparison includes the full retrieval pipeline and answer quality, rather than whether two products both advertise vector search.
The third is the expansion of managed distributed SQL. AWS describes Aurora DSQL as a serverless distributed SQL service with strong consistency. Such offerings raise the competitive standard for managed operations. Customers must still validate supported SQL features, transaction limits, regional availability and the latency implications of their actual architecture.
Structural debates: openness, reliability and bargaining power
Open source shifts value away from exclusive access to a database engine towards hosting, automation, support and complementary services. That can expand adoption while limiting pricing power. A provider needs reasons for customers to pay it specifically when competing services use familiar underlying technology.
Reliability can create durable pricing power because failure is expensive, but customer inertia is not unlimited. Cloud migration, application rewrites and contract renewals create opportunities to reconsider suppliers. AI coding tools may lower parts of migration effort while leaving the difficult work of validating correctness and operational recovery intact.
There is also a tension between a single versatile database and several optimised systems. Consolidation reduces integration and staffing burdens. Specialisation can improve performance for distinctive workloads. The sustainable winner is the architecture that meets business requirements at acceptable total cost; that conclusion can differ across applications within the same company.
What to watch
Watch production application growth, consumption per retained workload, customer concentration, service reliability and gross margin after hosting costs. Compare performance using realistic data sizes, concurrency, durability and recovery objectives. Developer enthusiasm is most valuable when it predicts applications that survive beyond a prototype.
For AI, track paid agent deployments, persistent state volumes, retrieval quality and the cost of serving useful requests. The central question is whether the database becomes harder to replace because it safely runs important work, or whether a growing list of interchangeable features weakens the supplier’s ability to charge for that work.
Explore this sector
Data platforms & analytics — sector overview
Related sectors: Semiconductors & chipmaking · AI infrastructure & data centres
