pre-commit is a framework to run hooks written in many languages, and it manages the language toolchain and dependencies for running the hooks.

When code gets cheap operational excellence wins. Anyone can build a greenfield demo, but it takes engineering to run a service.

Elasticsearch may work great in initial testing and development but Production is a different story. This blog is about what happens after you ship: the JVM tuning, the shard math, the 3 AM pages, the sync pipelines that break silently. The stuff your ops team lives with.

After years of teams running Elasticsearch in production, certain patterns keep emerging. The same issues show up in blog posts, Stack Overflow questions, and incident reports. We've compiled ten of the most common ones below, with references to the engineers who've documented them. We’ve also added images to make it easy to quickly skim through it and compare the challenges against Postgres.

TLDR: With great power comes great operational complexity.

For years, PostgreSQL has been one of the most critical, under-the-hood data systems powering core products like ChatGPT and OpenAI’s API. As our user base grows rapidly, the demands on our databases have increased exponentially, too. Over the past year, our PostgreSQL load has grown by more than 10x, and it continues to rise quickly.

The work around RegreSQL led me to focus a lot on buffers. If you are a casual PostgreSQL user, you have probably heard about adjusting shared_buffers and followed the good old advice to set it to 1/4 of available RAM. But after we went a little bit too enthusiastic about them on a recent Postgres FM episode I've been asked what that's all about.

Buffers are one of those topics that easily gets forgotten. And while they are a foundation block of PostgreSQL's performance architecture, most of us treat them as a black box. This article is going to attempt to change that.

I think the entire DevOps movement was a mighty, twenty year battle to achieve one thing: a single feedback loop connecting devs with prod. On those grounds, it failed.

Creative ideas for speeding up queries in PostgreSQL

This write-up presents a pure Terraform framework where 50+ teams deploy infrastructure using simple tfvars while platform teams maintain reusable building blocks. It highlights native lookup patterns, automated PR updates, and significant boilerplate reduction without adding preprocessing layers.

This article introduces tfplan2md, a tool that converts Terraform JSON plans into clearer markdown summaries for pull request reviews. It focuses on making plan output easier to understand in Azure DevOps and GitHub workflows.

This article explains why OpenTelemetry no longer recommends the batch processor for production durability-sensitive pipelines. It compares in-memory batching with exporter-level persistent queues and shows how the newer approach improves recovery during collector restarts.

This blog post is a comparison of personal, accessible, cloud backup options.

Tuckr is a dotfile manager inspired by Stow and Git. Tuckr aims to make dotfile management less painful. It follows the same model as Stow, symlinking files onto $HOME. It works on all the major OSes (Linux, Windows, BSDs and MacOS).

Tuckr aims to bring the simplicity of Stow to a dotfile manager with a very small learning curve. To achieve that goal Tuckr tries to only cover what is directly needed to manage dotfiles and nothing else. We won't wrap git, rm, cp or reimplement the functionality that are perfeclty covered by other utilities in the system unless it greatly impacts usability.

Yoke is a Helm-inspired infrastructure-as-code (IaC) package deployer designed to provide a more powerful, safe, and programmatic way to define and deploy packages. While Helm relies heavily on static YAML templates, Yoke takes IaC to the next level by allowing you to leverage general-purpose programming languages for defining packages, making it safer and more powerful than its predecessors.

XDR with eBPF-powered firewall and proxy.

Korrel8r is a rule-based correlation engine that automatically discovers and graphs relationships between cluster resources and observability signals across multiple data stores, enabling unified troubleshooting experiences.