Latest posts from Craig Kerstiens

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

It's been a little over a year since we launched Crunchy Bridge. We've been busy over the past year, focusing on the foundations of Crunchy Bridge, ensuring solid resiliency, reducing our high availability failover times, making upgrades seamless and smooth. There has been a lot of activity over the past few months so we thought it was time for an update. Consider this the first of many more to come on what we're up to. First, a little on how we think about Postgres and databases in general.

Let's start with Postgres. It's a great database. It has transactional DDL, multiple ways of indexing for improved query performance, a vast range of datatypes (JSONB

A lot of years Postgres will have some big pillar or theme to the release. Often this is thought of after the fact. Everything that is committed is looked at and someone thinks, "This is the key thing to talk about." In Postgres 9.2 it was JSON, in 9.4 it was JSONB, in 10 it was logical replication

Postgres has had "JSON" support for nearly 10 years now. I put JSON in quotes because well, 10 years ago when we announced JSON support we kinda cheated. We validated JSON was valid and then put it into a standard text field. Two years later in 2014 with Postgres 9.4 we got more proper JSON support with the JSONB

Reality is messy, and for every, "We've standardized on cloud Amazon, Azure, or GCP" announcement, there are tens or hundreds of apps hidden within an organization running on the "other" cloud. Most workloads don't span across clouds, but every large organization has workloads on each cloud vendor. And for everyone's favorite database (Postgres) we're excited to say you don't have to compromise quality when it comes to which cloud vendor you're running on. Today we're announcing Crunchy Bridge

Connection pooling and management is one of those things most people ignore far too long when it comes to their database. When starting out, you can easily get by without it. With 1 or 2 application servers spawning 5-10 connections, even the tiniest of Postgres servers can handle such. Even with our $35 a month hobby plan

Crunchy Data is pleased to announce its most recent release of pgBackRest: 2.33 with a number of new features including multiple repository support and GCS support. With pgBackRest 2.33 we are especially excited to add support for Google Cloud Storage

Last week I was on a call with someone giving an overview of Crunchy Bridge, our multi-cloud fully managed database as a service. During the call they asked about what was the best way to get a sense of how their database was doing, a health check

At most of the places I've worked, the primary language used was not what I gravitated to naturally. If you're going to ask for a language of choice personally, it's python. I appreciate the explicit nature, that it's often pseudocode that can execute and it has a rich ecosystem of libraries (though that’s most languages these days). But as much as anything I latched onto Django

Most database services in the cloud have not significantly evolved in the past 5 years. They tend to support the basics of read replicas and backups and then move on to other new shiny services, forgetting about a key pillar of your application: your PostgreSQL database. Today we're looking to change that with the launch of Crunchy Bridge