Today we're announcing Crunchy Bridge support for Managed Postgres on Google Cloud. With Crunchy Bridge you can now have the same great PostgreSQL experience on any cloud and seamlessly migrate between cloud vendors as you see fit.
What follows is a summary of conversations I've had with customers on how to think about key tenants of database management, high availability and disaster recovery.
When Linux detects that the system is using too much memory, it will identify processes for termination and, well, assassinate them. The OOM killer has a noble role in ensuring a system does not run out of memory, but this can lead to unintended consequences.
The recent selection of Postgres as the "Database of the Year" for the third time in four years is by no means an overnight success story, but is well deserved recognition for a database decades in the making. As organizations look for the relational database of the future, Postgres is ready and waiting. We are proud to be among the leading contributors and supporters of this important movement.
Today I'm changing the memory speed on my main test system, going from 2133MHz to 3200MHz, and measuring how that impacts PostgreSQL SELECT results. I'm seeing a 3% gain on this server, but as always with databases that's only on a narrow set of in-memory use cases.
This week Apple started delivering Macs using their own Apple Silicon chips, starting with a Mac SOC named the M1. M1 uses the ARM instruction set and claims some amazing acceleration for media workloads. I wanted to know how it would do running PostgreSQL, an app that's been running on various ARM systems for years. The results are great!
In this blog post, we'll discuss how to set up streaming replication in Windows. Credit goes to my colleague Douglas Hunley whose blog post on setting up streaming replication on Linux served as inspiration.
Apple's Intel-based laptops are very popular among developers, and that's as true of people who work on PostgreSQL as other groups. Tomorrow, the first shipping Apple laptops running on ARM CPUs instead of Intel are expected.
As a database grows and scales up from a proof of concept to a full-fledged production instance, there are always a variety of growing pains that database administrators and systems administrators will run into.
When should you be alerted about issues in your PostgreSQL clusters? How do you troubleshoot them? What are some typical solutions?
What are some PostgreSQL monitoring stats that are typically used to monitor the health of your databases?
What are some of the key stats to look at to ensure your PostgreSQL cluster is healthy? How can you use this stats to diagnose the problem?
PostgreSQL 13 was released last week. I'm excited about this one, as the more mature partitioning plus logical replication features allow some long-requested deployment architectures