# high availability Published articles for high availability. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Red Hat edge platforms: Choosing the right one for your use case DevFeed: [Red Hat edge platforms: Choosing the right one for your use case]() Original publisher: [Read original article]() Author: Daniel Froehlich Published: 2026-09-11T13:01:48Z Content type: article Language: en Sources: [Red Hat](), [Red Hat Developer]() Topics: [Edge](), [Containers](), [Kubernetes](), [Architecture & Design](), [Hardware](), [Availability](), [Microservice]() Tags: [containers](), [deployment](), [edge](), [edge-computing](), [hardware](), [high-availability](), [kubernetes](), [management-tools](), [microservices](), [red-hat](), [virtual-machines]() ### AI overview This article introduces a series about choosing Red Hat edge platforms for specific deployment needs. It compares Red Hat Enterprise Linux and Red Hat OpenShift across workload types, platform sizes, hardware requirements, Kubernetes use cases, availability, storage, and management needs. ### Source excerpt Choosing the right platform for an edge deployment is one of the most consequential decisions an organization makes--and one of the most confusing. The options range from a single-board computer running a handful of containers to a full Kubernetes cluster with high availability, software-defined storage, and centralized management. Pick too small, and you hit a wall when requirements grow. The post Red Hat edge platforms: Choosing the right one for your use case appeared first on Red Hat Developer. ## Enabling TLS in PXC without Downtime DevFeed: [Enabling TLS in PXC without Downtime]() Original publisher: [Read original article]() Author: Juan Arruti Published: 2026-09-09T23:32:15Z Content type: tutorial Language: en Sources: [Blog - Percona]() Topics: [TLS (Transport Layer Security)](), [Replication](), [Security](), [Network](), [openssl]() Tags: [galera](), [high-availability](), [insight-for-dbas](), [mysql](), [open-source](), [percona](), [pxc](), [replication](), [security](), [ssl](), [tls](), [tls-handshake](), [uncategorized](), [xtradb-cluster-pxc]() ### AI overview This tutorial explains how to enable TLS for replication traffic in Percona XtraDB Cluster without a full cluster restart. Using Galera's socket.dynamic option, operators can perform two rolling restarts: first allowing encrypted and plaintext connections, then enforcing TLS-only communication. ### Source excerpt Starting with Percona XtraDB Cluster (PXC) 8.0, replication traffic encryption is enabled by default. That said, it's common to find clusters running without TLS that suddenly need it: a new compliance requirement, an audit finding, a network segment that is no longer considered trusted. PXC has a variable for exactly that case, pxc-encrypt-cluster-traffic, which handles ... Continued The post Enabling TLS in PXC without Downtime appeared first on Percona. ## 7 Simple Home Lab HA Projects for This Weekend DevFeed: [7 Simple Home Lab HA Projects for This Weekend]() Original publisher: [Read original article]() Author: Brandon Lee Published: 2026-09-05T12:22:03Z Content type: tutorial Language: en Sources: [Virtualization Howto]() Topics: [Homelab](), [Availability](), [Pi-hole](), [Docker](), [Containers]() Tags: [availability](), [containers](), [dns](), [docker](), [high-availability](), [home-lab](), [home-server](), [server](), [servers]() ### AI overview This article presents seven simple high-availability projects for a home lab. Its detailed example recommends running two DNS servers, separating them across Docker hosts, configuring primary and secondary DNS addresses, and synchronizing the DNS platforms. ### Source excerpt A lot of times we think about high availability being some complicated or complex thing that we just think in the home lab it isn't worth doing. However, HA doesn't... The post 7 Simple Home Lab HA Projects for This Weekend appeared first on Virtualization Howto. ## I Thought Keepalived Only Protected My Home Lab Servers. Then I Found Track Scripts DevFeed: [I Thought Keepalived Only Protected My Home Lab Servers. Then I Found Track Scripts]() Original publisher: [Read original article]() Author: Brandon Lee Published: 2026-09-04T12:32:34Z Content type: tutorial Language: en Sources: [Virtualization Howto]() Topics: [Homelab](), [Availability](), [Linux](), [Proxmox](), [Network](), [Protocol (disambiguation)](), [Docker](), [Server](), [configuration]() Tags: [availability](), [dns](), [docker](), [high-availability](), [home-lab](), [home-server](), [linux](), [network](), [proxmox](), [servers](), [virtualization]() ### AI overview The article explains how Keepalived provides high availability for home lab servers by moving a virtual IP address between Proxmox hosts using VRRP. It focuses on track scripts, which allow failover decisions based on application-level checks rather than only complete server failure, with Docker-based DNS services as an example. ### Source excerpt I have used Keepalived in my home lab for quite some time and most of the time, I have thought of it in a very simple way as to what... The post I Thought Keepalived Only Protected My Home Lab Servers. Then I Found Track Scripts appeared first on Virtualization Howto. ## How to verify your Azure Application Gateway is zone-redundant DevFeed: [How to verify your Azure Application Gateway is zone-redundant]() Original publisher: [Read original article]() Author: Andre Newman Published: 2026-09-04T00:00:00Z Content type: article Language: en Sources: [Gremlin Blog]() Topics: [Azure](), [Availability](), [Cloud](), [web applications](), [Command-line interface](), [Shared Responsibility Model]() Tags: [availability](), [azure](), [cli](), [cloud](), [features](), [high-availability](), [how-to](), [infrastructure](), [post](), [shared-responsibility](), [web-applications]() ### AI overview This how-to article explains availability-zone redundancy for Azure Application Gateway. It describes the redundancy model, the shared responsibility boundary, and how to verify whether a gateway is zone-redundant or zonal using Azure CLI and Resource Graph. It also cautions that a redundant gateway does not by itself make the services behind it redundant. ### Source excerpt This post explains what zone redundancy means for Application Gateway, how to confirm whether a given gateway is zone-redundant or zonal using the Azure CLI and Resource Graph, and why a gateway surviving a zone failure doesn't mean the services calling through it will. ## KIOXIA CM9-R 15.36TB Review: BiCS8 Flash Hits Full Speed at Low Queue Depths DevFeed: [KIOXIA CM9-R 15.36TB Review: BiCS8 Flash Hits Full Speed at Low Queue Depths]() Original publisher: [Read original article]() Author: Brian Beeler Published: 2026-09-02T16:13:32Z Content type: article Language: en Sources: [StorageReview.com]() Topics: [datacenter](), [Security](), [Availability](), [configuration](), [.NET Framework](), [dell](), [intel](), [Nvidia]() Tags: [dell](), [enterprise](), [fips-140-3](), [high-availability](), [intel](), [lts](), [nvidia](), [pcie](), [performance](), [review](), [security](), [ssd](), [ubuntu]() ### AI overview This review evaluates the 15.36TB E3.S KIOXIA CM9-R enterprise SSD, built on eighth-generation BiCS FLASH. It highlights strong low-queue-depth performance, including 3,400K random read IOPS, 14,800 MB/s sequential read, 11,000 MB/s sequential write, and 540K random write IOPS, while emphasizing a typical active power rating of 25W. The drive supports PCIe 5.0 x4, dual-port operation, NVMe 2.0, NVMe-MI 1.2c, power-loss protection, end-to-end data protection, and optional security variants. ### Source excerpt The KIOXIA CM9-R is the first enterprise SSD family built on eighth-generation BiCS FLASH, and the 15.36TB E3.S model in our lab is the volume sweet spot of the range: 3,400K random read IOPS and 14,800 MB/s of sequential read from a drive with a 25W typical active rating. Gen5 enterprise drives routinely push into The post KIOXIA CM9-R 15.36TB Review: BiCS8 Flash Hits Full Speed at Low Queue Depths appeared first on StorageReview.com. ## How Razorpay Cut Its Metrics Bill by 62% Without Losing a Dashboard DevFeed: [How Razorpay Cut Its Metrics Bill by 62% Without Losing a Dashboard]() Original publisher: [Read original article]() Author: Dhairya Mehta Published: 2026-08-24T10:25:21Z Content type: article Language: en Sources: [Razorpay Engineering - Medium]() Topics: [Monitoring](), [migration](), [incident](), [Self-hosted](), [telemetry]() Tags: [cost](), [high-availability](), [incident](), [metrics](), [migration](), [monitoring](), [self-hosted]() ### AI overview Razorpay reduced daily metrics ingestion from about 450 billion to about 170 billion samples, cutting its metrics bill by 62% without deleting useful dashboards or breaking alerts. The article describes an audit conducted during a planned migration from a self-hosted VictoriaMetrics cluster to a managed monitoring platform, covering scrape intervals, duplicate high-availability scrapes, and high-cardinality metrics. ### Source excerpt Contributor: Saijal Shrivastava We cut our metrics ingestion by 62% without deleting a single useful dashboard or breaking an alert. Daily ingestion dropped from about 450 billion samples to about 170 billion. The surprising part was not one large optimization. It was three simple discoveries hiding in plain sight: Scrape intervals can multiply ingestion. High-availability scraping can silently send duplicate metrics when deduplication happens only at the storage layer. High-cardinality metrics are easy to create, expensive to keep, and hard to remove without ownership. We found these while preparing to move from a self-hosted VictoriaMetrics cluster to a managed monitoring platform. The migration started as a reliability project. The audit turned it into a cost and signal-quality project. We were not just moving monitoring data. We were moving years of accumulated assumptions about what was worth scraping. The Incident that Forced the Audit Our self-hosted VictoriaMetrics cluster had served us well for years. Then one storage node hit EBS volume throttling. Traffic shifted to the remaining storage nodes, the extra load pushed another node past its limits, and the storage layer collapsed. We saw the same pattern whenever a storage node became unavailable: traffic redistributed, the remaining nodes overloaded, and the cluster moved back toward failure. The collection, ingestion, and query components were still running, so the system looked alive from the outside. But the storage layer was down. Metrics stopped being persisted. Dashboards went blank. Alerts stopped evaluating. Recovery took hours. Teams fell back to logs and manual checks to understand production health. Figure 1: Cascading failure in the pipeline That made the reliability problem obvious. We needed a more stable monitoring architecture. We evaluated several options: self-hosted designs with disaster recovery built in, and fully managed alternatives. But when we priced the managed options, one number ## Understanding Load Balancing for Beginners DevFeed: [Understanding Load Balancing for Beginners]() Original publisher: [Read original article]() Author: Pramodh Kumar M Published: 2026-08-17T17:00:34Z Content type: tutorial Language: en Sources: [Kubernetes - KodeKloud Blog | DevOps, Cloud, Kubernetes, AI Tutorials & More]() Topics: [backends](), [networking](), [Algorithms]() Tags: [backend](), [beginners](), [cloud](), [connection-draining](), [devops](), [failover](), [health-checks](), [high-availability](), [kubernetes](), [layer-4-vs-layer-7](), [least-connections](), [load-balancer](), [load-balancer-for-beginners](), [load-balancing](), [load-balancing-algorithms](), [networking](), [nginx](), [round-robin](), [session-affinity](), [sre](), [sticky-sessions](), [thundering-herd](), [traffic-management]() ### AI overview This beginner-oriented article explains load balancing as both traffic distribution and backend failure detection. It compares round robin and least-connections algorithms, distinguishes Layer 4 from Layer 7 routing, and discusses health checks, failover, draining, sticky sessions, and the risks of overly aggressive checks. ### Source excerpt Spreading traffic is the easy half of load balancing. The half that decides whether an outage lasts ten seconds or ten minutes is noticing that a backend has stopped working, and most health checks cannot. ## Multi-Region PostgreSQL Disaster Recovery and Failback with Crunchy PGO DevFeed: [Multi-Region PostgreSQL Disaster Recovery and Failback with Crunchy PGO]() Original publisher: [Read original article]() Author: Wellingtone Luvonga Published: 2026-08-11T05:00:00Z Content type: tutorial Language: en Sources: [CYBERTEC PostgreSQL | Services & Support]() Topics: [PostgreSQL](), [Disaster Recovery](), [Kubernetes](), [MinIO](), [nginx](), [TLS (Transport Layer Security)](), [Amazon S3](), [Availability]() Tags: [availability](), [backup](), [data-recovery](), [disaster-recovery](), [failover](), [high-availability](), [how-to](), [kubernetes](), [minio](), [nginx](), [postgresql](), [recovery](), [s3](), [tls](), [tutorials]() ### AI overview A tutorial on using Crunchy PostgreSQL Operator on Kubernetes to implement multi-region PostgreSQL disaster recovery and failback. It covers secure MinIO-backed WAL storage through an NGINX TLS reverse proxy, regional failover, and reversing roles without timeline conflicts or archive poisoning. ### Source excerpt This blog talks about multiregion PostgreSQL disaster recovery using Crunchy PGO. It has some detailed steps to understand better. The post Multi-Region PostgreSQL Disaster Recovery and Failback with Crunchy PGO appeared first on CYBERTEC PostgreSQL | Services & Support. ## PostgresBench: Measuring the impact of High Availability on Managed Postgres performance DevFeed: [PostgresBench: Measuring the impact of High Availability on Managed Postgres performance]() Original publisher: [Read original article]() Author: Lionel Palacin; Sai Srirampur; Andrey Chudnovskiy Published: 2026-07-21T16:13:25Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [Benchmark](), [Availability](), [PostgreSQL](), [clickhouse](), [Replication](), [Cloud]() Tags: [aws](), [benchmarks](), [clickhouse](), [comparison](), [high-availability](), [performance](), [postgres](), [replication]() ### AI overview PostgresBench measures the performance cost of high-availability configurations across managed Postgres services. The article explains shared-nothing and shared-storage architectures, compares availability and durability approaches, and describes how compute resources and configurations were matched for fair benchmarking. ### Source excerpt PostgresBench now includes HA benchmarks, comparing the performance of managed Postgres services under production-style HA configurations. This post explains the architectures behind each service and analyzes the trade-offs between availability guarantees ## Scale Faster with Managed Weaviate: Now in Public Preview on DigitalOcean DevFeed: [Scale Faster with Managed Weaviate: Now in Public Preview on DigitalOcean]() Original publisher: [Read original article]() Author: Waverly Swinton Published: 2026-07-09T19:08:52Z Content type: release Language: en Sources: [DigitalOcean]() Topics: [Digital Ocean](), [Cloud](), [Databases](), [Retrieval Augmented Generation (RAG)](), [autoscaling](), [Self-hosted](), [GraphQL](), [gRPC]() Tags: [autoscaling](), [configuration](), [database](), [databases](), [digitalocean](), [graphql](), [high-availability](), [hosting](), [infrastructure](), [preview](), [product-updates](), [real-time](), [rest](), [retrieval](), [run](), [security](), [storage](), [upgrades](), [workflows]() ### AI overview DigitalOcean has placed Managed Weaviate into public preview. The service provides fully managed Weaviate clusters with automated backups, security patching, version upgrades, high availability, and storage autoscaling, with pricing starting at $20 per month. ### Source excerpt Production Weaviate in minutes, managed by DigitalOcean. Starting at $20/month. Vector databases have become a core piece of the AI application stack. Whether you're building retrieval-augmented generation (RAG), semantic search, agentic workflows and memory, or similarity-based recommendations, you need a vector store that's reliable, fast, and doesn't require a dedicated ops engineer to keep running. Weaviate has become a critical part of that stack -- its open-source AI-native vector database powers semantic search, RAG, and agentic workflows for thousands of companies. Self-hosting Weaviate is doable but it comes at a cost. You're on the hook for backups, version upgrades, security patches, high availability configuration, and storage scaling. That's real time and real engineering capacity that isn't going toward your product. Managed alternatives from larger cloud vendors exist, but they often come with per-query fees, per-dimension surcharges, and pricing models that are difficult to predict as usage grows. Today, we're announcing that Managed Weaviate is now in public preview on DigitalOcean, offering an easy way for you to run Weaviate in production, at a price that makes sense from day one. The easiest way to run Weaviate in production Managed Weaviate on DigitalOcean handles the operational work so you don't have to. Provision a fully managed Weaviate cluster directly from the DigitalOcean control panel. From there, automated backups, security patching, version upgrades, high availability, and storage autoscaling are handled for you. Full Weaviate client compatibility via GraphQL, REST, and gRPC on port 443 means your existing code works without modification. This means you get Weaviate's full capabilities -- semantic and hybrid search, RAG pipelines, and support for agent-driven workflows -- without spending engineering time on the infrastructure beneath them. Predictable pricing, starting at $20/month We built Managed Weaviate with flat, predictable monthly ## Keycloak 26.7.0 released DevFeed: [Keycloak 26.7.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-07-09T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [API](), [Authentication](), [Authorization](), [Security](), [OAuth 2.0](), [saml]() Tags: [api](), [authentication](), [authorization](), [deprecated](), [haproxy](), [high-availability](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [oauth](), [oauth-2-0](), [openid-connect](), [persistence](), [provisioning](), [release](), [saml](), [security](), [sso](), [traefik]() ### AI overview Keycloak 26.7.0 introduces preview support for SCIM-based user provisioning and simplified multi-cluster high availability, along with enhanced HAProxy and Traefik reverse-proxy guidance and step-up authentication for SAML clients. The release also adds a more secure, OAuth 2.0-compliant Identity Brokering API v2, while V1 remains enabled by default but is deprecated. OID4VCI improvements remain experimental. ### Source excerpt To download the release go to Keycloak downloads. Highlights This release features new capabilities for users and administrators of Keycloak. The highlights of this release are: Automate user provisioning with the SCIM API (preview) Simplified multi-cluster high availability without external caches (preview) Enhanced reverse proxy guides with blueprints for HAProxy and Traefik Step-up authentication for SAML clients Read on to learn more about each new feature. If you are upgrading from a previous release, also review the changes listed in the upgrading guide. Security and Standards Stronger security for the Identity Brokering API The Identity Brokering API allows applications to retrieve tokens obtained from external identity providers during federated login. Version 2 of this API replaces the legacy V1 with a more secure and standards-compliant design: Client-level authorization -- access to external tokens is controlled per client using dedicated settings (Allow retrieve external tokens and an identity provider allow list) instead of assigning broker roles to individual users. Confidential clients only -- public clients are rejected, ensuring that only authenticated clients can retrieve external tokens. OAuth 2.0 compliant -- the endpoint uses POST and returns standard JSON responses with access_token, error, and error_description fields. Session-based token storage -- a new Store token in session option keeps tokens in the user session for faster access, with automatic cleanup on session expiry. Database storage remains available for persistence across sessions. V2 is now supported but disabled by default. V1 is deprecated but still enabled by default for backward compatibility. In a future release, V1 will be removed and V2 will become the default. For more information, see the Identity Brokering APIs chapter in the Server Developer Guide. Progress on Verifiable Credentials (OID4VCI) (experimental) Verifiable Credentials (OID4VCI) allow organizations to issue tampe ## Multigres v0.1 Alpha: an operating system for Postgres DevFeed: [Multigres v0.1 Alpha: an operating system for Postgres]() Original publisher: [Read original article]() Author: Sugu Sougoumarane Published: 2026-06-04T07:00:00Z Content type: release Language: en Sources: [Supabase Blog]() Topics: [Open Source](), [Availability](), [Kubernetes](), [Databases](), [Orchestration](), [Replication](), [Deployment](), [systems](), [vitess]() Tags: [availability](), [aws](), [backup](), [cloud](), [database](), [deployment](), [high-availability](), [kubernetes](), [open-source](), [orchestration](), [postgres](), [release](), [replication](), [s3](), [scale](), [storage](), [systems](), [vitess]() ### AI overview Multigres v0.1 alpha is an open-source system for scaling and operating Postgres. It provides connection pooling, automatic failover, backup orchestration, sharding, and horizontal scaling, with Kubernetes deployment support and high-availability features based on Postgres replication and generalized consensus. ### Source excerpt Today we're releasing Multigres v0.1 alpha to the open source community, bringing Vitess-grade horizontal scaling, high availability, and operational simplicity to Postgres. ## Building High Availability PostgreSQL Clusters with Patroni and Other Integrated Approaches DevFeed: [Building High Availability PostgreSQL Clusters with Patroni and Other Integrated Approaches]() Original publisher: [Read original article]() Author: Agus Syafaat Published: 2026-05-21T07:20:00Z Content type: tutorial Language: en Sources: [SeveralNines]() Topics: [postgresql clusters](), [PostgreSQL](), [Availability](), [Replication](), [Resilience](), [Automation](), [configuration](), [Open Source]() Tags: [automation](), [availability](), [configuration](), [consensus](), [database](), [distributed](), [failover](), [ha](), [high-availability](), [open-source](), [patroni](), [postgresql](), [postgresql-clusters](), [recovery-repair](), [replication]() ### AI overview This article explains how to build highly available PostgreSQL clusters with Patroni and related tools. It describes Patroni's use of replication, distributed consensus, a distributed configuration store, leader election, health checks, and YAML configuration to support automated failover. It also discusses operational challenges and the possible use of ClusterControl in the workflow. ### Source excerpt In modern application stacks, downtime is a direct threat to business continuity, customer trust, and revenue. Regardless of whether it is an e-commerce platform, a fintech application, or a critical internal system, the expectation is 24/7 availability, underscoring the critical importance of High Availability (HA) and automated failover mechanisms within PostgreSQL clusters. HA ensures that [...] The post Building High Availability PostgreSQL Clusters with Patroni and Other Integrated Approaches appeared first on Severalnines. ## Egress problems and where to find them DevFeed: [Egress problems and where to find them]() Original publisher: [Read original article]() Author: Simeon Griggs Published: 2026-05-14T00:00:00Z Content type: article Language: en Sources: [Blog -- PlanetScale]() Topics: [Databases](), [Database](), [data](), [App](), [Cloud]() Tags: [applications](), [availability](), [cloud](), [data](), [database](), [databases](), [efficiency](), [high-availability](), [performance](), [postgres](), [product](), [reduce](), [scale]() ### AI overview The article explains how reducing database egress by fetching less data and making requests less frequently can improve application performance while lowering costs. It focuses on Postgres examples, including query limits, selecting specific columns, and extracting needed values from JSONB data. ### Source excerpt Reducing the size and frequency of requests to your database has the double benefit of making your applications faster and cheaper. ## ClickHouse Monitoring and Observability Decision Points DevFeed: [ClickHouse Monitoring and Observability Decision Points]() Original publisher: [Read original article]() Author: Paul Namuag Published: 2026-04-17T07:00:00Z Content type: tutorial Language: en Sources: [SeveralNines]() Topics: [clickhouse](), [Monitoring](), [observability](), [Scalability](), [Availability](), [Replication](), [Latency]() Tags: [capacity](), [clickhouse](), [efficiency](), [high-availability](), [latency](), [logs](), [metrics](), [monitoring](), [monitoring-alerting](), [observability](), [operations](), [ops](), [optimization](), [partitioning](), [performance](), [replication](), [scalability](), [scale](), [traces]() ### AI overview This article explains why ClickHouse deployments need monitoring and full observability because distributed clusters, replicas, scalability, and real-time analytics create operational complexity. It outlines using metrics, logs, traces, and alerting to detect bottlenecks, optimize queries, track resource use, monitor pipeline health, plan capacity, troubleshoot distributed queries, and support availability. ### Source excerpt Given ClickHouse's ability to execute complex analytical queries across terabytes of data in a single operation, proper monitoring and observability is critical. Its distributed architecture and scalability add layers of complexity, as multi-node clusters require careful coordination monitoring across shards and replicas to ensure data consistency and availability. Adding to the operational pressure is users' [...] The post ClickHouse Monitoring and Observability Decision Points appeared first on Severalnines. ## Introducing the SQL Server on Kubernetes Operator DevFeed: [Introducing the SQL Server on Kubernetes Operator]() Original publisher: [Read original article]() Author: Anthony Nocentino Published: 2026-04-12T05:00:00Z Content type: tutorial Language: en Sources: [Kubernetes on Anthony Nocentino's Blog]() Topics: [Kubernetes](), [sql-server](), [Availability](), [Disaster Recovery](), [Open Source]() Tags: [automated](), [automatic](), [availability](), [availability-groups](), [containers](), [disaster-recovery](), [failover](), [high-availability](), [kubernetes](), [open-source](), [operator](), [sql-server]() ### AI overview This tutorial introduces sql-on-k8s-operator, an open-source Kubernetes operator for managing SQL Server workloads. It addresses high availability and disaster recovery by automating lifecycle management, failover, and Always On Availability Group setup, and demonstrates deployment with custom resources. ### Source excerpt Are you considering replatforming your SQL Server workload due to recent vendor changes, but still need high availability and disaster recovery? You're not alone. One of the challenges with running SQL Server on Kubernetes is that there's no Kubernetes operator available. That means no automated lifecycle management, no automatic failover, and no standard way to bootstrap an Always On Availability Group on Kubernetes. I'm excited to share it today as an open-source project: sql-on-k8s-operator. Let's go. ## Managed Databases Are Now Available in Laravel Forge DevFeed: [Managed Databases Are Now Available in Laravel Forge]() Original publisher: [Read original article]() Author: Laravel Team Published: 2026-03-17T15:48:55Z Content type: release Language: en Sources: [Laravel Blog]() Topics: [Laravel](), [postgresql clusters](), [Availability](), [Provisioning](), [Monitoring](), [Replication](), [Network](), [VPC]() Tags: [compute](), [databases](), [datacenter](), [high-availability](), [laravel](), [learn](), [memory](), [monitoring](), [network](), [postgres](), [replication](), [security](), [storage](), [vpc]() ### AI overview Laravel Forge now offers managed PostgreSQL clusters provisioned directly from its dashboard. The service handles patching, backups, replication, failover, and monitoring, with configurable compute, storage, region, networking, and high-availability options. ### Source excerpt Let Laravel Forge handle managed Postgres clusters for you with automated backups, PITR, high availability, and monitoring, all from your Forge dashboard. ## Active-Active MySQL Group Replication Best Practices DevFeed: [Active-Active MySQL Group Replication Best Practices]() Original publisher: [Read original article]() Author: Paul Namuag Published: 2026-03-11T12:54:52Z Content type: tutorial Language: en Sources: [SeveralNines]() Topics: [MySQL](), [Replication](), [Scalability](), [Availability](), [Transactions]() Tags: [availability](), [best-practices](), [consensus](), [consistency](), [deployment-scaling](), [high-availability](), [mgr](), [mysql](), [mysql-group-replication](), [replication](), [scalability](), [transactions]() ### AI overview This article explains active-active MySQL Group Replication, where multiple primary members accept concurrent writes that are synchronously replicated and coordinated through consensus and write-set certification. It discusses scalability limits, transaction conflicts, rollback surges, and operational considerations for production deployments. ### Source excerpt In MySQL Group Replication (MGR) or Group Replication, an active-active configuration allows multiple group members to accept concurrent write transactions. These writes are coordinated through a consensus-based group communication system (GCS) and validated via write-set certification to preserve global transactional consistency as defined by the Group Replication protocol. active-active mode is designed for write scalability. [...] The post Active-Active MySQL Group Replication Best Practices appeared first on Severalnines. ## Scaling Payments in the Age of Real-Time Fraud: Building a Resilient Foundation for Fintech DevFeed: [Scaling Payments in the Age of Real-Time Fraud: Building a Resilient Foundation for Fintech]() Original publisher: [Read original article]() Author: Becca Weng Published: 2026-02-25T00:00:00Z Content type: article Language: en Sources: [Cockroach Labs]() Topics: [systems](), [Architecture & Design](), [Resilience](), [Availability](), [consistency](), [Low Latency](), [data]() Tags: [fintech](), [high-availability](), [latency](), [outages](), [payments](), [pci-dss](), [real-time](), [security](), [sensitive-data]() ### AI overview This article explains why fintech payment systems require resilient architectures that preserve atomic data updates, maintain low latency during demand spikes, support global regulatory and data-residency requirements, and provide high availability and security. It also introduces real-time fraud detection as an added source of complexity. ### Source excerpt Fintech is one of the most competitive and highly regulated industries in the world. Whether you're a payment processor, digital-first bank, trading platform, or wallet provider, your infrastructure is directly tied to customer trust. In this environment, outages aren't just technical incidents; a single missed transaction, delayed authorization, or moment of downtime can erode customer confidence instantly. ## Why etcd breaks at scale in Kubernetes DevFeed: [Why etcd breaks at scale in Kubernetes]() Original publisher: [Read original article]() Author: Daniele Polencic Published: 2026-02-24T00:00:00Z Content type: tutorial Language: en Sources: [Learnk8s]() Topics: [Kubernetes](), [Database](), [Raft](), [Availability]() Tags: [api-server](), [consistency](), [database](), [high-availability](), [kubernetes](), [raft](), [scale]() ### AI overview This article explains why etcd becomes a bottleneck as Kubernetes clusters grow. It describes etcd as the API server's private, consistent backend and explains how Raft supports shared state across multiple API servers for high availability. ### Source excerpt etcd is the database behind every Kubernetes cluster. This article explains etcd's design limits, how the API server amplifies them, and what you can do about it -- from sharding to what GKE, EKS, and k3s built. ## Building an enterprise Postgres service in ClickHouse Cloud DevFeed: [Building an enterprise Postgres service in ClickHouse Cloud]() Original publisher: [Read original article]() Author: Sai Srirampur Published: 2026-02-20T10:05:10Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [Cloud](), [Replication](), [Availability](), [real-time](), [Streaming](), [data](), [distributed-systems]() Tags: [analytics](), [availability](), [clickhouse](), [cloud](), [data](), [enterprise](), [high-availability](), [integration](), [postgres](), [real-time](), [replication](), [streaming]() ### AI overview This article describes the development of an enterprise Postgres service managed by ClickHouse Cloud. It covers cross-availability-zone high availability with synchronous standbys, quorum-based streaming replication, automatic failover, dedicated read replicas, and failover-safe change data capture into ClickHouse for real-time analytics. ### Source excerpt We've been investing heavily in state-of-the-art features to ensure customers get an enterprise-grade Postgres experience. ## How to optimize real-time data ingestion in Snowflake and Iceberg DevFeed: [How to optimize real-time data ingestion in Snowflake and Iceberg]() Original publisher: [Read original article]() Author: Sesethu Mhlana Published: 2026-01-21T00:00:00Z Content type: article Language: en Sources: [Redpanda]() Topics: [real-time](), [Apache Iceberg](), [Streaming](), [Kafka](), [data-governance](), [systems]() Tags: [cost](), [data](), [data-governance](), [high-availability](), [infrastructure](), [integration](), [kafka](), [monitoring](), [performance](), [pipelines](), [real-time](), [schema](), [storage](), [streaming]() ### AI overview This guide explains how architectural inefficiencies in real-time data ingestion can increase Snowflake credits, storage costs, and query delays. It focuses on streaming pipelines involving Apache Iceberg and describes the infrastructure overhead of Kafka deployments, including brokers, coordination services, connectors, schema registries, and monitoring. ### Source excerpt Learn about the hidden costs of real-time data ingestion and practical strategies to optimize your streaming infrastructure. ## What's new in ClickHouse - 2025 roundup DevFeed: [What's new in ClickHouse - 2025 roundup]() Original publisher: [Read original article]() Author: ClickHouse Published: 2026-01-20T00:00:00Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [Architecture & Design](), [autoscaling](), [Cloud](), [real-time](), [Availability](), [Apache Iceberg]() Tags: [analytics](), [architecture](), [clickhouse](), [cloud](), [features](), [high-availability](), [infrastructure](), [performance](), [real-time](), [scale]() ### AI overview ClickHouse's 2025 roundup covers infrastructure and performance improvements, including SharedCatalog, stateless compute, Warehouses, vertical scaling, single-replica services, and horizontal scaling. It highlights cloud-scale metadata coordination, compute separation, high-availability workloads, and support for open table formats such as Iceberg and Delta Lake. ### Source excerpt A look back at what we shipped in 2025. [Next page]()