I would actually argue that CockroachDB isn't really a pure OLTP play, nor does it really want to be one. If you read some of their more recent literature like

I would actually argue that CockroachDB isn't really a pure OLTP play, nor does it really want to be one. If you read some of their more recent literature like [1], it seems pretty clear to me that they're headed towards building a "good enough" one-size-fits-all [2] database solution, one that can do both OLTP and OLAP on the same data (i.e. HTAP). Furthermore, it seems to me that query evaluation techniques aren't really that different between OLTP and OLAP workloads, i.e. the difference is mainly in the storage format. In that sense, I think it follows that Spark is a good fit as the query layer. Notice phrasings like "arbitrary computations close to your data". That's basically exactly what Spark already is. I think there's a lot of synergy in combining it with a strongly consistent distributed storage engine. Anyways, my $0.02, evidently not a very popular opinion ¯\_(ツ)_/¯ [1] https://www.cockroachlabs.com/blog/local-and-distributed-processing-in-cockroachdb/ https://www.cockroachlabs.com/blog/local-and-distributed-pro... [2] https://cs.brown.edu/~ugur/fits_all.pdf https://cs.brown.edu/~ugur/fits_all.pdf