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 of course to be highlighted), and a really rich ecosystem of extensions that enable whole new use cases such as geospatial support via PostGIS.
But Postgres hasn't always been the most developer friendly database. If you were trying to setup HA 10 years ago good luck... and even now it's not built-in to the core. Almost everyone will recommend you run Postgres with a connection pooler yet most hosts provide one out of the box or charge for it as an add-on. Our goal with Crunchy Bridge is to do better. Our goal is to make Postgres easier to use, to give you all the tools right of the box to be ready for production, and to build on Crunchy Data's collected expertise around Postgres to highlight how you can better use it–without you having to get a PhD in databases.
So what exactly have we been up to? Here's a few highlights from the past couple of months.
A new look
First, we have a fresh coat of paint on Crunchy Bridge. We've rebuilt our front end to give it a cleaner design aesthetic, but more importantly to allow us to move faster in delivering features to you. With this new look we've also snuck in a few other features we'll talk about more in the below sections, so make to explore.
In place upgrades
In addition to being able to resize your instance sizing and scale storage, you can now also self-service schedule an in place upgrade of a major version of Postgres. In place upgrades behind the scenes will bring up a replica, then perform pg_upgrade on that replica, and finally promote it to be your primary. This operation takes just a few seconds and is related to the size of catalog (not the size of your data). Upgrading a database that is a few TB should be just as easy as a small 10 GB one.
Postgres 14 support
PostgreSQL 14.0 was released just over a week ago on Thursday (no not a beta, not an RC, the Postgres 14). About 6 hours later we had support for it live on Crunchy Bridge. You can provision a fresh Postgres 14 instance and give it a try, or give in place upgrade a try on your existing Crunchy Bridge cluster.
Maintenance windows serve two purposes within Crunchy Bridge. First, if we ever have to perform emergency upgrades due to underlying packages or security fixes the upgrade will be performed during that window. Second, any resize operations whether to disk, to instance sizing, or Postgres version upgrades will be performed during that window. If you don't set a window upgrade and resizes will be performed as soon as the replica is ready. We recommend you set your maintenance window for all of your production clusters today.
Just getting started
At the core of all this our job is to keep your data safe, keep you up and running, and well tuned for production. A few highlights for the unfamiliar.
We're available on:
- AWS (15 regions)
- Azure (12 regions)
- GCP (10 regions)
Within Bridge you get:
- Backups, disaster recovery, point in time recovery all included
- Ability to replicate/migrate between clouds
- Built-in pgbouncer
- VPC isolation and peering
- Full Postgres superuser support
- Pl/Python and Pl/R support
For us all the above is exciting, but it is just the beginning. It's the foundation of a good managed database provider. Now we're as focused as ever on making your developer experience simple, so your database fades as away an afterthought and you can build cool things. Stay tuned for what's coming, but a quick preview...