OLTP as you mentioned is used for transactional purposes. It means you are writing small objects at high concurrency in OLTP databases. These databases require higher consistency levels and require high availability. OLTP databases are generally used in the user path.
Now, can't we use OLTP databases for OLAP purposes? Yes absolutely you can use but that would be suboptimal. The analytics queries are long-running queries. A large analytic query might require minutes to run and might require reading many many rows of the OLTP database.
While the analytics query is going on, the OLTP database will add read locks to the rows that are accessed by the analytic query and will not relinquish the lock till the query is complete. This is all based on 2 phase locking paradigm. Thus, these rows will not be writeable by any transactional query making the transactional queries wait or retried.
This is a problem. We are using the OLTP databases for high-speed concurrency but now the database rows are locked due to a large analytics query. This reduces the availability of the OLTP.
What does it mean to business? If OLTP database rows are locked for a long time, the actual customer will not be able to make changes to them. You can map this to any business use case. The end customer is impacted due to internal analytics queries running.
This quandary is avoided by adding a dedicated OLAP database instead of running the analytics query in the same OLTP database.
Another way to look at, the OLAP databases don't require to be highly available as we will be running internal analytics queries to it and no customer directly accessing the OLAP DB. So we can keep these databases separate to avoid any conflict with the direct customer query path.
