I recently wrote an example of how you can project monthly recurring revenue (MRR) in Postgres. This is a helpful metric to understand how a subscription-based business is doing and can help inform all sorts of financial and operational decisions at the company.

Since writing that example, my same friend running their SaaS business on Crunchy Bridge

You've built an application and are using Postgres to run it. You move it into production. Things are going great. So great that you've accumulated so much data that you need to resize your disk.

Before the cloud, this often involved either expanding your disk partitioning or getting a new disk, both of which are costly operations. Cloud has made this much easier: disk resizes can occur online or transparently to the application, and can be done as simply as clicking a button (such as in Crunchy Bridge

Crunchy Data products often include High Availability. Patroni and etcd are two of our go-to tools for managing those environments. Today I wanted to explore how these work together. Patroni relies on proper operation of the etcd cluster to decide what to do with PostgreSQL. When communication between these two pieces breaks down, it creates instability in the environment resulting in failover, cluster restart, and even the the loss of a primary database. To fully understand the importance of this relationship, we need to understand a few core concepts of how these pieces work. First, we'll start with a brief overview of the components involved in HA systems and their role in the environment.

Overview of HA Infrastructure

Whether you are starting a new development project, launching an application modernization effort, or engaging in digital transformation, chances are you are evaluating Kubernetes. If you selected Kubernetes, chances are you will ultimately need a database

Crunchy Data is proud to announce an update to the CIS PostgreSQL Benchmark by the Center for Internet Security (CIS). CIS is a nonprofit organization that publishes best practices and standards for securing modern technology and systems. This newly published CIS PostgreSQL 14 Benchmark ads to the existing CIS Benchmarks for PostgreSQL 9.5 - 13 and builds upon Crunchy Data's ongoing efforts with the PostgreSQL Security Technical Implementation Guide

As more data workloads shift to running on Kubernetes, one of the important topics to consider is security of your data. Kubernetes brings many conveniences for securing workloads with the ability to extend security functionality databases through the use of the Operator pattern

Encrypting data at rest is often an important compliance task when working on securing your database system. While there are a lot of elements that go into securing a PostgreSQL database, encrypting data at rest helps to protect your data from various offline attacks including the stealing of a disk or tampering. Disk encryption is a popular feature among public database-as-a-service providers, including Crunchy Bridge,

Many years ago a group of colleagues and I latched onto this idea of flow and what it means for developer experiences. Flow was one of those things that was always hard to measure, but you could tell when it was right or wrong. It wasn’t about KPIs or deploy metrics, but it was about the overall efficiency of the process. A big part of flow when it came to DX was a great CLI experience.

A great CLI is intuitive, it allows you to work efficiently while building on simplicity. A great CLI can be key to developer flow.

In developing our CLI for Crunchy Bridge

Monthly recurring revenue (MRR) and annual recurring revenue (ARR) are important metrics for a subscription-based business model. It allows for the business to project its available capital to make important decisions around expansion, hiring and more.

In an on-demand subscription model, MRR can fluctuate on any given day. This is especially true in the cloud-services world, where people are constantly spinning up and down services. That's why it makes sense to try and capture what the subscription revenue "run rate" is: this is a projection of how much money you are earning over a period of time based upon current service usage.

This exercise recently came up with a friend who was looking for a little help with analyzing and reporting on their SaaS business which is running on Crunchy Bridge

One of the reasons why I like deploying Postgres on Kubernetes with PGO, the open source Postgres Operator