We want to test early and more often. This is what shift-left refers to. Instead of testing applications just before the release, we want to test our applications early to identify issues when it’s still easy to fix them. However, shifting to the left carries much bigger consequences. Let’s see what.

Imagine a world where you don’t have to worry about your database, no bugs are deployed to production, all the performance checks happen early during the development phase, you don’t need DBAs nor the maintenance team, and still, everything works great. No matter how fantastic that sounds, you can get it today. Read on to learn how.

We wanted to calculate a unique identifier for each SQL query in the database. See how we solved this challenge.

Achieving database reliability is not easy. We need to take care of many components, like data integrity, recoverability, performance, and security. However, we need to do it no matter who we are and what our business is. Our customers demand that. The reliability of a database directly impacts the efficiency, reputation, and success of an organization, making it an indispensable asset in today's data-driven world.

When running multi-tenant applications spanning hundreds of clusters and databases, it’s not uncommon to build extensive maintenance pipelines, monitoring, and on-call rotations to achieve database reliability. Many things can break, starting with bugs, inefficient queries written by developers, or inefficient configuration and indexing. Do you worry about your databases? You’re doing it wrong. Read on to see how to stop worrying and still have continuous database reliability.

As developers, we all strive to write the best code that performs great when deployed. It is true when we’re writing our application code, and the same applies when it comes to our databases! Wouldn’t it be great if you could feel confident when changing your code? Would you like to deploy with no stress? Would you like to get automated confirmation that your changes to the database or business logic will not take your production database down? Read on to learn how to have all of that.

In today’s world, it’s even more important for platform engineers and engineering leaders to push ownership of databases to the left and make developers own their databases. The organization needs to automate as much as possible and minimize communication between teams. While we achieved many improvements in the DevOps area and even included other aspects in the same way like security (with DevSecOps), configurations (with GitOps), or machine learning (with MLOps), we still keep databases out of the loop. Let’s see why that is a problem and why we should make developers own their databases.

As developers, we all strive to keep our systems in shape. We maintain them, we review metrics and logs, and we react to alerts. We do whatever it takes to make sure that our systems do not break, especially databases that are crucial to our applications. Wouldn’t it be great if there was no need to do the maintenance at all? Would you like to just have tools that could take care of your databases and let you forget that they exist altogether? Read on how to do that.

In this article, we’re going to see how database bugs can negatively affect our business and how we can protect ourselves from dire consequences.

In PostgreSQL, the slow query log is a feature that allows you to log queries that take longer than a specified threshold to execute. This log helps you identify and optimize queries that may be causing performance issues in your database. Let’s see how we can use it.