by Pawel Brzoska

Intro

It’s been intense 10 months... Talking with customers, gathering their points of view and requirements, then building the idea, vision, the roadmap, finally gathering the team and starting development. First customer installations, valuable feedback, another iteration, adding more value to the product, checking quality, performance, ease of use, documentation, but we are finally here - at the point where we can without doubt announce : we are production ready!

Who are we

“Alright, but I’ve never heard of you!” some may be thinking. So, let’s start from the beginning: innovating in the database layer is hard, right? How many  database migrations have you seen struggle or even fail? Migrating data to a new platform or schema is tough on its own, and a smooth transition on the client side—whether to a new app or UI—can be even harder. Often, it requires building from scratch or adapting to a new system, with inevitable functionality gaps and a lengthy ramp-up time..

That’s why so few organizations tackle it. And it’s why new database vendors have trouble breaking through, despite offering better performance and costs than legacy vendors entrenched for decades. 

But that’s not how it should be! We should NOT be blocked from innovating! We should be able to set our data free and decide where to keep them, where they belong, and what is the best performance-to-cost factor we want to have even if that means changing the DB platform every two years (sure, by then, there will be something better than today, right?).

That’s why we founded Quesma: to empower customers to make those choices.

We believe that separating data and client/application/UI layers will bring similar effects as breaking down the code monolith into microservices in the application stack world.

Kibana on ClickHouse

Our fist use case, as some you might have heard, is around Elastic stack and modern OLAP columnar databases like ClickHouse. Many vendors have picked ClickHouse as their backend platform for Observability and Security use cases for log management, which proves it is the technology of choice for this type of data. We recently announced a partnership with one of them, a testament to our capabilities.

Yet, many customers remain hesitant to move from Elasticsearch/OpenSearch to newer platforms.

Why? As our partners tell us, users fear losing Kibana’s unparalleled analytical capabilities. Yes, there's a Grafana plug-in for ClickHouse, but who wants to write SQL queries to build dashboard panels? Besides - have you used Loki’s Explore interface? Exactly…

This is where Quesma comes in: we separate Kibana, Logstash, and other elements of the Elastic ecosystem and unbundle them from Elasticsearch so you can set your data free and decide where to keep it without losing the capabilities of the application layer.

Quesma acts as a bridge between Kibana and ClickHouse, translating EQL queries to SQL and back. The result? You can keep using Kibana or OpenSearch Dashboards while your data resides in ClickHouse, delivering 10x speed at 10% of the cost.

So, don't wait! Check out our GitHub and feel free to play with Quesma in your test environment. And in case you need more information and help from us, including a demo or trial - get in touch.