Executing transactions is not atomic and takes time. For example, a single UPDATE statement might modify multiple rows, and the database system needs time to update each row. During this update process, another transaction might start and attempt to read the modified rows. This raises the question: should the other transaction read the new values of the rows (even if not all rows are updated yet), the old values of the rows (even if some rows have been updated), or should it wait? What happens if the first transaction must be canceled later for any reason? How should this affect the other transaction? Read on to understand!

Memory usage is one of the most important aspects of the database system. Having not enough memory directly affects every performance metric and negatively impacts the performance. This in turn affects our users and the business. In this blog post, we are going to understand how databases (and PostgreSQL specifically) manage memory and how to troubleshoot low free-memory scenarios.

Logging is one of the most important parts of the distributed systems. Many things can break, but when the logging breaks, then we are completely lost. In this blog post, we will understand log levels and how to log efficiently in distributed systems.

A connection pooler is a software component that manages database connections. This can help in multiple ways to improve resource utilization, help with load balancing or failover, and can greatly reduce transaction times. In this blog post, we’re going to see what a connection pooler is and how to configure it.

Every read from a physical drive is a tremendous performance hit and should be avoided. In this blog post, we are going to see how to debug scenarios where we can’t utilize cached data and need to read from the physical drive. We’re going to see why it’s important, what to look for, and what tools and extensions to use.

We must understand how to move fast and increase velocity with databases and what new tools and processes we need to build around. This comes down to incorporating database guardrails and moving towards DBOps. Starting and scaling DevOps in the enterprise is only the beginning. DevOps automation tools helped us achieve improvements in many areas of software development, but now we need to see how to move forward with DBOps. In this article, we’re going to explore how to build DevOps for databases called DBOps and how it can scale efficiency and drive business growth

Are you sure that your CI/CD covers everything? While it may sound obvious, there are so many things that we miss. We don’t check our queries properly, we don’t control configurations, and we don’t cover non-functional requirements in general. Let’s see what 5 things we lack in our CI/CD pipeline and why they are crucial in today’s world.

This agility in managing database schema changes is key to maintaining speed and flexibility in our database strategies. But how can we move fast around databases? How can we be agile in the database world? Read on to see.

Reliability is not something we can just build in one place. We need to make sure all parts of the ecosystem work together to guarantee reliability everywhere. One unstable component can take down the whole system. And there is no more important component than the database. The domain model and the storage affect the whole system heavily as it affects every single operation in your application. A good product starts with a good database.

Do you rely on your monitoring solutions to let you know when things are wrong? That is so brave of you! On a more serious note, please think twice. Monitoring is not enough! It can’t explain why things happen the way they do (because it doesn’t see the past beyond metrics) and it doesn’t tell you what is going to happen (so it can’t predict the future). This is a serious problem and we need a solution (spoiler alert: we need database guardrails). Let’s read on to understand why.