7 min read · 12 sources

Datadog is rolling out a lightweight tier to cut host monitoring costs on staging environments, while Kubernetes maintainers are finally treating workload behavioral drift as an upstream testing bug. At the same time, the ceiling for durable execution on vanilla relational engines just moved dramatically upward.

If you have spent the last three years running secondary fleets on basic metrics daemons just to avoid vendor agent taxes, or rebuilding custom test matrices every time an EKS minor release rolls out, today brings concrete upstream and platform updates.

Advisory locks eliminated a cascading contention loop, allowing 50 PostgreSQL shards to scale cleanly from 20,000 to one million durable workflows per second.

Datadog splits the agent bill with Infrastructure Basic

Source: datadoghq.com ↗

Datadog released Infrastructure Basic, a lower-tier monitoring option targeting non-critical infrastructure, internal tools, and staging instances. The tier runs the standard Datadog Agent in a stripped-down mode, gathering fundamental host-level telemetry: CPU, memory utilization, disk usage, disk I/O, network stats, system uptime, system load, and basic process status.

Crucially, metrics collected under Infrastructure Basic keep full-resolution retention for 15 months, matching high-tier plans for year-over-year capacity planning. It includes standard alerting profiles and out-of-the-box dashboards, alongside integrations with incident platforms like PagerDuty and ServiceNow. Teams can run Basic alongside Pro and Enterprise agents inside the same organization, meaning operators no longer have to deploy separate Prometheus or Telegraf stacks just to avoid paying full-suite prices on development boxes.

Kubernetes launches Workload Conformance Working Group

Source: kubernetes.io ↗

Every Kubernetes operator knows the pain of an API version surviving a minor upgrade while the runtime behavior of the workload silently degrades. Upstream is addressing this gap directly with the Workload Conformance Working Group.

Historically, Kubernetes conformance tests validated whether an infrastructure provider implemented the control plane and API specs correctly. They never guaranteed that identical Pod specifications behave identically across versions during node drains, network shifts, or resource exhaustion. The new working group is drafting a runtime behavior specification spanning seven areas:

• Security contexts and privilege escalation boundaries
• Workload resilience during node disruptions and eviction
• Resource scheduling and cgroup limits
• Network namespace routing and service resolution
• CSI volume attachment and lifecycle guarantees
• Controller API usage patterns
• Standardized runtime observability

The WG plans to release a binary test harness for upstream CI within two to three release cycles. The goal is simple: continuous, reproducible conformance tests that catch behavioral changes before an upgrade breaks traffic routing or graceful pod termination in production.

Supabase Compute moves agents inside the database boundary

Source: supabase.com ↗

Supabase announced the private alpha of Supabase Compute in us-west-2. The service deploys long-running containers alongside managed database instances, targeting long-lived tasks that exceed the wall-clock execution boundaries of edge functions - such as continuous background syncs, custom HTTP endpoints, and autonomous agents.

Containers provision via the Supabase CLI (v2.120.0+) with sizing options currently fixed at 2 GB RAM / 1 vCPU or 4 GB RAM / 2 vCPU. Services automatically inherit project secrets, network bindings, and log drains. For data-dense operations, the physical co-location avoids cross-region TLS handshakes: internal user testing showed data agent query latencies dropping from 65 ms across regions down to a median of 2.9 ms on local compute. Autoscaling is absent in the alpha, meaning workloads remain pinned to static profiles for evaluation.

Scaling GitOps: One Argo CD hub across 34 clusters

Source: cloudnativenow.com ↗

Managing multi-tenant Kubernetes via GitOps frequently degrades into sprawling credential stores and cluster configuration drift. A production retrospective by Nitish Mane on managing 34 clusters with a single Argo CD hub details how to tame fleet sprawl across 22 AWS accounts and one Oracle Cloud tenancy.

The setup drives 1,214 Argo CD Application objects sourced from 174 shared Helm charts using a centralized control plane. Instead of embedding custom manifests per target, cluster onboarding is reduced to a concise declarative contract of roughly 20 YAML keys. Short-lived cross-account IAM roles handle cluster authentication, eliminating static kubeconfig tokens in the control plane. By combining pre-merge CI manifest diffs with explicit prune protections, the engineering team cut cluster onboarding time from four business days to 1.7 hours without risking accidental cascading deletions.

Self-service infrastructure via Backstage and Terraform

Source: spacelift.io ↗

Engineering teams attempting to offer platform self-service without opening their state files to wild edits can look at Spacelift’s blueprint for integrating Terraform with Spotify’s Backstage.

The architecture uses Backstage strictly as a catalog front-end and parameter collection layer. When a developer requests an RDS database or an S3 bucket via Backstage Software Templates, the portal does not execute Terraform commands directly. Instead, it generates a pull request with standardized HCL against the platform repository. The Spacelift plugin surfaces the resulting speculative plan and run status inside the Backstage UI. This keeps Git as the immutable audit log and leaves state management, drift detection, and OPA policy evaluation to the dedicated CI/CD pipeline.

DBOS benchmarks 1,000,000 durable workflows per second on Postgres

Source: dbos.dev ↗

Building durable, distributed execution engines usually requires dedicated coordination systems like Temporal or specialized event buses. DBOS demonstrated that vanilla PostgreSQL can run over 1,000,000 workflows per second by horizontal sharding across 50 db.m7i.4xlarge AWS RDS instances (16 vCPUs, 64 GB RAM each).

The ingestion and execution tier ran 48 concurrent workers per shard, handling 20,000 workflow operations per second per database node with PgDog managing connection pooling. The primary bottleneck encountered was a cascading contention loop: whenever an individual Postgres node suffered a momentary I/O hiccup, worker processes backed up, enqueued redundant dequeue transactions, and triggered massive row-level lock contention on the workflow table.

Engineers stabilized the system by enforcing Postgres advisory locks to throttle concurrent dequeue routines. With connection limits strictly gated, throughput scaled linearly from 20,000 writes on a single instance to a flat 1,000,000 durable executions across the fleet.

+-------------------------------------------------------------+
|                      DBOS Worker Fleet                      |
|           (PgDog Connection Pooling & Advisory Locks)       |
+-------------------------------------------------------------+
        |                    |                    |
        v                    v                    v
+----------------+   +----------------+   +----------------+
| RDS Instance 1 |   | RDS Instance 2 |   | RDS Instance 50|
| 20k ops/sec    |   | 20k ops/sec    |   | 20k ops/sec    |
+----------------+   +----------------+   +----------------+
        |                    |                    |
        +--------------------+--------------------+
                             |
                 1,000,000 Workflows / sec

The residual risks in GitHub Actions pwn requests

Source: wiz.io ↗

Wiz published an analysis detailing the state of pull_request_target vulnerabilities following GitHub’s platform hardening rollout. GitHub has addressed several insecure defaults: actions/checkout@v7 blocks checking out untrusted fork heads by default, token cache controls are now read-only, and safety patches were back-ported to checkout tags v2 through v6. On December 2, GitHub will enforce a default policy blocking pull_request_target usage on public repositories entirely.

However, dangerous escape hatches remain:

• Immutable Commit Pinning: Teams that pin actions to full commit SHAs dating before the July 2026 backport release do not receive the patched checkout behavior.
• Alternative Triggers: Attackers target pipelines driven by issue_comment or workflow_run, which retain write privileges and access to repo secrets without the restrictions placed on pull_request_target.
• Private Repositories: The upcoming December 2 block only affects public repositories. Internal corporate organizations remain exposed to internal lateral movement via forked repos.

Auditing CI configurations for manual git checkouts or downstream evaluations of untrusted expressions like ${{ github.event.comment.body }} remains mandatory.

Automation and isolation in brief

Source: github.blog ↗

• GitHub Agentic Workflows GA: GitHub’s Agentic Workflows are now generally available. The platform lets engineers define task-oriented coding agents inside repository Markdown documents that compile down to GitHub Actions YAML. The system supports self-hosted Action Runner Controller (ARC) deployments, Docker-in-Docker isolation, and network egress sandboxing to contain automated CI debugging agents.
• AWS EKS Fargate internals: A deep-dive into EKS Fargate’s architecture breaks down its single-pod isolation model. Rather than packing pods onto shared multi-tenant instances, Fargate uses a custom mutating admission webhook to redirect scheduled pods to an internal scheduler. The scheduler provisions a microVM with a dedicated Elastic Network Interface (ENI) assigned directly to the customer VPC, eliminating node-level noisy neighbor and container breakout risks at the hypervisor boundary.
• OpenTelemetry GenAI Conventions: Splunk’s writeup on standardizing AI observability shows how OpenTelemetry’s GenAI conventions are emerging as the common format for LLM evaluation. Standardizing conversation spans, token tracking, and latency metrics under OpenTelemetry prevents vendor lock-in across commercial inference endpoints.
• Macro: The open-source project Macro published its SolidJS and Rust codebase. Built around a unified bidirectional graph database, it joins messages, documentation, ticketing, and tasks into a single traversable schema designed to give automated assistants complete context without multiple SaaS integrations.
• DeepTutor: The open-source DeepTutor engine released version 1.7.0, adding modular installations, resumable vector embeddings for long documents, and native Gemini speech streaming, providing local orchestration components for multi-modal internal training environments.