Kubernetes-native scale-to-zero with zero traffic loss, no code changes, and direct integration with kubernetes resources

The OpenTelemetry Operator is an implementation of a Kubernetes Operator.

Zarf eliminates the complexity of airgap software delivery for Kubernetes clusters and cloud-native workloads using a declarative packaging strategy to support DevSecOps in offline and semi-connected environments.

The SR-IOV Network Device Plugin is Kubernetes device plugin for discovering and advertising networking resources in the form of:

- SR-IOV virtual functions (VFs)
- PCI physical functions (PFs)
- Auxiliary network devices, in particular Subfunctions (SFs)

which are available on a Kubernetes host

"Oops, I accidentally deleted my Docker registry. Can I get my images back?" YES. This tool does exactly that.

A cautionary tale about AWS VPC networking, NAT Gateways, and how a missing VPC Endpoint turned our S3 data transfers into an expensive lesson.

Postgres has an awesome amount of data collected in its own internal tables. Postgres hackers know all about this - but software developers and folks working with day to day Postgres tasks often miss out the good stuff.

The Postgres catalog is how Postgres keeps track of itself. Of course, Postgres would do this in a relational database with its own schema. Throughout the years several nice features have been added to the internal tables like psql tools and views that make navigating Postgres’ internal tables even easier.

Today I want to walk through some of the most important Postgres internal data catalog details. What they are, what is in them, and how they might help you understand more about what is happening inside your database.

After stumbling on a pair of interesting blog posts — You Don’t Need Kafka, Just Use Postgres (Considered Harmful) — somewhat in the style of good old “flame wars” (which are increasingly rare these days) in the recent Postgres Weekly, as a response to a previous article — Kafka is fast – I’ll use Postgres — on using Postgres for “Kafkaesque” business, I felt the urge to chip in a bit.

But first off — I’d like to laud the authors of both pieces. They’re well-argued reads with a crazy amount of good tidbits and food for thought. I especially liked that the original one tried to be open and repeatable and actually tested things. Gunnar’s take was maybe a bit too morbid for my taste, of course 🐘

To recap — the main question in the debate was whether Postgres is generally “good enough” to implement a low-to-medium volume event queue or even a pub-sub system. The general sentiment from Hacker News readers at least was that unless scale truly demands Kafka, Postgres is indeed good enough — and many teams plain overestimate their scaling needs and don’t actually need Kafka’s distributed complexity.

Spoiler: there’s obviously no definitive answer as to when one should use a “proper” database for something — and there sure are reasons why we have so many purpose-specific databases: relational, event logs, analytical column stores, key-value, time-series, ledger, graph, hierarchical, document, blob, text search, vector, …

Anyway, below are some thoughts that came to mind — I can’t go too deep on Kafka though, as I’m just not qualified enough.