The issue is no matter if you are using a column store or simulating a column store in a row store you will have to do tuple reconstruction. Unless all of you q

The issue is no matter if you are using a column store or simulating a column store in a row store you will have to do tuple reconstruction. Unless all of you queries really only need one attribute this will require at least one join. Some column stores use clever techniques, like cracker columns, to make these joins faster. This is why a column store may perform better than a row store for specific kinds of queries. But if your queries are constantly asking the dmbs to re-construct the a relation with many attributes a row store may actually work better for you. My point is that the decision to choose your dbms should be driven by, the kind of data you have, and the kind of queries you are going to run. If performance really matters to you, you should really do some empirical testing before choosing the technology. Both there is some give and take here, one is not definitively better than the other. That said I agree with you that this is a bad solution don't simulate a column store with a row store it won't perform as well as a good column store since it is not optimized for tuple reconstruction.