I'd like to argue that conventional notions of OLTP are ill fitted to modern CRUD/SaaS apps.
OLAP claims to be optimized for read-heavy workloads. But looking at access patterns for SaaS/CRUD apps, data shows the read/write ratio is along the order of 90/10
Additionally, OLTP purportedly deals in entire rows while OLAP is selective about columns and may contain aggregate functions/derived data.
But think about things like GraphQL, Firebase/Supabase, OData, etc
It's common in modern APIs to ask for a selective, minimal number of columns and also calculate derived information to display on a page
To me, the types of apps I've built my entire career sound much more like OLAP than OLTP, but we wouldn't call them that?
Misses Data Mesh, buzzwords too outdated
Only thing interesting mentioned here to me is Apache Iceberg and it looks to be very early in development.
Being able to evolve schemas overtime is useful. I'll look into it again in a few years.
A read replica of your OLTP db, will get you a long way before worrying about all of the complexities and inefficiency of the buzzword based approaches.
I'm pretty sure this is puff piece for Dremio, which is yet another attempt to create commercial software on top of a valuable set of open-source tools, namely apache arrow.
In general, i think we are in the final throws of discrete, "enterprise" analytical data architecture. The cloud is quickly making analytical uses case just another storage/query product. Especially as tools like AWS Lake Formation and Palantir come to maturity, we won't need special concepts like "Data Lake" any more.
Also -- OLAP, really? 2000 called, it want's it's buzzwords back...
It's marketing bs. Olap is a special case of oltp with a dedicated dimensional client. Data lakes are just cloud NFS at petabytes scale, data warehouses try to wrap everything (except olap) holistically together. There are layers upon layers of complexity for each of those in production and they all feel insane to me. they all stop short of putting into practice a unified data management theory.