Infobright database employed as part of a new new Greenfield product we were building. We tried several times to migrate to a different solution.

We were successful in moving a portion of the geographic searchable data into Elastic Search and only use Infobright for storage of the fine-grained data.

Yes, MySQL. The amount of dataexceeded the limit MySQL (free version) normally works with.

We had not used column-oriented database before Infobright.

We used a relational database, MySQL along side Hadoop. At the time, I believe Hadoop was difficult to rely on and the operation between Hadoop and MySQL were very intensive.

I used many different databases, Oracle, PostgreSQL, MySQL, Teradata, SQL Server, among others.

With most of them, ad hoc performance, ease of use, no need for physical design and tuning, ability to create extremely large and fast denormalized tables -- those are amongst the most prominent reasons.

Also, small footprint and huge savings with compression was a factor.

The setting up and running project was much faster than with the alternatives. That and relatively low cost would dramatically effect my projects and allow my clients to realize big savings, while getting BI faster to the user and monetizing the information faster, too.

I used row-based proprietary DB for a few years. To meet my goals, however, I switched to this solution. Columnar DB are faster and are simpler than row-based solutions. With Columnar DB, there is no need to create an index, analyze the table/index, tune the structure, etc.

On the contrary, we have switched back to the MS SSAS Tabular Model, because of pricing policy. The Infobright annual subscription price for one year of usage is more expensive than a full MS SQL Enterprise license.

It has been our key engine in the columnar database landscape.