Sotolongo's lineage is Twitter observability -> Google streaming -> Snowflake Dynamic Tables, which is a declarative, relational, query-optimizer-centric tradition. Marz's lineage is Storm -> Trident -> Rama, which is a procedural-dataflow, programmer-controls-the-plan, event-sourcing-centric tradition. Both are trying to unify OLTP + OLAP + application logic + reactivity into a coherent substrate, but they're coming at it from opposite epistemological poles. Rama says "give the programmer fine-grained control over partitioning, indexing, and dataflow, and trust them to design the right physical representation for their queries." Cambra, if your inference about Dynamic Tables is right, will almost certainly say "let the programmer describe the domain model declaratively and let the system figure out the physical representation." This is the classic Codd-vs-Codasyl split, recapitulated forty years later with much more sophisticated machinery on both sides.

If this is the right framing, then the two systems aren't really competitors despite solving the same problem--they're going to appeal to fundamentally different developer sensibilities. Rama is for people who want to think like Jay Kreps or Martin Kleppmann: the event log is sacred, physical data layout is a first-class design decision, and the programmer earns the performance benefits by understanding the system deeply. Cambra (if these assumptions hold) will be for people who want to think like database users: describe what you want, let the optimizer figure out how, intervene only when necessary. These are both defensible positions and both have historical track records of working. SQL's history shows the declarative camp has ecosystem advantages once the optimizer is good enough; Kafka/Rama's history shows the log-centric camp has correctness and observability advantages for event-heavy domains.