Balancing between row and columnar DBs

Columnar databases have a lot of benefits, especially for OLAP workloads. Rows-based is also still in the game, but mostly applied to OLTP? Is there a well-balanced solution? Probably yes.

Last days I was actively writing about aspect-oriented approaches that seems to be such balance. Each database record has a lot of aspect in it. For instance "users" table frequently contains lifetime aspect (createdAt, deletedAt, etc), authentication  (login, password, blocked), person (firstName, lastName), address (country, city, etc), many payment aspects (because many types of payments), etc.

Storing each aspect, not an each field in a vertical partition, like columnar databases  do, looks to be a good balance. We usually work with entities in scope of some aspect. E.g. when you're authenticating an user, you don't need its address. Making a payment doesn't involve it's authentication details, etc.

So when we are authenticating, we use the only vertical partition responsible for this aspect. And as a result - minimum of IO operations (works only with required subset of columns).

It will be encoded and stored as effective as columnar databases but with less overhead. And mostly beat row-based engines. For example ones those support clustered indexes will be able to have more that one per virtual table because physically one clustered index will be allowed for the each aspect-partition.