Databases are the software in which an app stores its records and reads them back while it runs: each order, message, payment or bank balance, saved the moment it happens. This zone covers operational databases, the ones an app writes to. The copies that are later added up sit in a separate data warehouse.
Consider a ride-hailing app in Pune at 9 a.m. In one second it may record hundreds of new trips, update the location of thousands of drivers, and charge hundreds of fares. Each of these is a small write. It must be saved at once, and it must never be lost. This is the transactional work called OLTP, explained on the page on OLTP and OLAP.
Different records suit different kinds of database. So one app often uses several.
A relational database stores records as rows in tables that point to each other. The ride app keeps its trips and fares here, because money needs the strict checks that relational databases give. A document database stores each record as one document, such as a rider's profile with all its saved places. A key-value store saves each value under one key and finds it in under a millisecond, such as each driver's latest location. It often keeps its data in memory, an idea explained on the page on caching. A graph database stores the links between records, such as riders who share a phone or a payment card, which helps to find fraud.
Some databases change how the data is spread. A distributed SQL database works like a relational database, but keeps copies on many machines and in several cities, so that one failure stops nothing. This is redundancy. An HTAP database also answers analytical questions on the live data, without waiting for a copy to reach the warehouse. A multi-model database holds documents, graphs, time-stamped readings and vector embeddings in one store.
Many of these databases are open source: anyone can download them and run them free. So the companies behind them earn in other ways, as the open source business model explains. A company that runs a free database on its own servers can buy open-source database support for the day it breaks. Or it can rent database as a service (DBaaS), in which another company runs the database in the cloud.
The choice of database is hard to reverse. A company's code and years of its data are built around it, and moving means rewriting code and copying every record without losing one. This is called vendor lock-in. Copies of the records leave the database through data pipelines.