Sounds like you've engineered a great way to manage complexity while using an RDBMS. A few things that Rama provides above this: * Rama's indexing is much more

Sounds like you've engineered a great way to manage complexity while using an RDBMS. A few things that Rama provides above this: * Rama's indexing is much more flexible. For example, if you need to have a nested set with 100M elements, that's trivial. An index like that is common for a social graph (user ID -> set of follower IDs). If you need a time-series index split by granularity, that's equally as trivial (entity -> granularity -> time bucket -> stat). * There are no restrictions on data types stored in Rama. * Rama queries are exceptionally powerful. Real-time, on-demand, distributed queries across any or all of your indexes is trivial. * Rama has deep and detailed telemetry across all aspects of an application built-in. This doesn't need to be separately built/managed. * Deployment is also built-in. With your approach, an application update may span multiple systems – e.g. worker code, schema migrations – and this can be a non-trivial engineering task especially if you want zero downtime. Since Rama integrates computation and storage end-to-end, application launches, updates, and scaling are all just one-liners at the terminal. * Rama is much more scalable. This is looking at Rama from a feature point of view, and it's harder to express how much of a difference the lack of impedance mismatches makes when coding with Rama. That's something you learn through usage. Rama is for the JVM, so any JVM language can be used with it. Currently we expose Java and Clojure APIs.