>no single point of failure (redis and likely the rdbms as well) Your README mentions replication in the Operational characteristics, but it does not cover par

>no single point of failure (redis and likely the rdbms as well) Your README mentions replication in the Operational characteristics, but it does not cover partition tolerance? - Is there one master per cluster? - What happens when the network becomes segmented? It is also unclear of how this affects multiple clusters. - How is a global consensus of the data reached? - What happens when the network becomes segmented between clusters? >no need to maintain two very different systems SQLite isn't a full featured RDBMS. It mainly lacks support for stored procedures and concurrency. It is a very nice solution for small, self contained, horizontally scalable usage scenarios. However, once the use case involves generating custom globally unique identifiers (like a 7 character alphanumeric string) it generally falls apart. >scalable. As in plug in a new cluster and it will proportionally increase capacity. Redis and RDBMS have well known use cases for replication and partition management. Redis itself is single threaded, so it is horizontally scalable by your budget (and likewise supports sharding and replication albeit the network segmentation can lead to issues). More full featured RDBMS like Postgres, MariaDB, Oracle, and SQL Server support concurrency and granular locking with similar scaling strategies. I do not see the value proposition in consolidating the infrastructure in this case.