As more organizations move their databases to cloud-native environments, effectively managing and monitoring these systems becomes crucial. According to Coroot’s anonymous usage statistics, 64% of projects use PostgreSQL, making it the most popular RDBMS among our users, compared to 14% using MySQL. This is not surprising since it is also the most widely used open-source database worldwide.

There is a phenomenal amount of Observability tools on the market, coming in all shapes and sizes, offering many tools and approaches to solve what seems to be an endless number of problems. It also can be overwhelming to use, hard to set up and expensive to run, especially if you are going with SaaS based market leaders like DataDog.

When you build software, its terminology, concepts and relationship between them is quite obvious to you, when you’re starting to use software built by someone else – might not be so much so. In this blog post I tried to cover most important Coroot concepts and terminology – reading it will hopefully help you to understand Coroot much better if you’re just starting up with it.

At Coroot, we’re passionate about providing developers with the tools they need to build and maintain high-performing applications. Recently, we had the opportunity to help a team using FerretDB, the open-source document database offering MongoDB compatibility with a PostgreSQL backend, significantly improve their monitoring and performance. This is their story.

We’re excited to announce Coroot v1.6, packed with major improvements and new features to make observability even better! Here’s what’s new.

If you’re an experienced engineer, you likely have comprehensive observability and monitoring set up for your production systems. So if issues arise, you’re empowered to resolve them quickly. Yet, there are way too many systems out there, especially smaller and simpler ones, which are running with only rudimentary observability systems, or no observability at all. This means when an application goes down or starts to perform poorly, it may be very hard to pinpoint and resolve the issue.

You are running a complex, mission-critical application, and you understand you need an advanced Observability solution to efficiently troubleshoot and proactively prevent issues. Yet you have a choice to make—should you choose a “Fully Managed” SaaS solution such as Datadog, Newrelic, or Dynatrace, or should you pick an Open-Source solution that you can host yourself?

I’ve heard this story many times from production engineers: ‘We use tools like Datadog and NewRelic, but to keep costs from skyrocketing, we’re only monitoring our most critical services. We’re storing just 10% of our logs and traces and only the metrics we consider essential. It’s a frustrating situation. Engineers want full visibility across their systems, but cloud storage costs make it impossible to monitor everything.