OffNet Newsroom

Archive snapshot

Friday, October 16, 2026

Daily signal on databases, AI, and the tech that matters.

37 new today 40 stories 7 sections 18 for the DBA desk

Database Technology 8

roundup ↗

Restoring Amazon RDS for PostgreSQL from snapshots triggers lazy EBS volume hydration, causing query performance to degrade by 10x to 15x initially. To mitigate this, AWS highlights PostgreSQL-native prewarming strategies such as using pg_prewarm, running VACUUM ANALYZE, or executing full table scans. New monitoring fields have also been introduced to help operators track hydration progress and restore predictable performance faster.

  • Lazy EBS hydration causes significant query latency spikes immediately after snapshot restore.
  • Use pg_prewarm or full table scans to proactively hydrate data pages before traffic resumes.
  • VACUUM ANALYZE helps update statistics and can assist in faster recovery of performance metrics.
  • Leverage new monitoring fields to observe hydration status and validate performance recovery.
  • Pre-warming is critical for maintaining SLA compliance during automated or manual restores.
PostgreSQL News database

PostgreSQL 19 RC 1 Released; GA Targeted for Nov 19, 2026

The PostgreSQL Global Development Group has released the first release candidate for version 19, which is expected to be largely identical to the final GA release. The team decided to incorporate a significant batch of fixes scheduled for the November 12 update release directly into the RC1 build. A second release candidate, RC 2, will be issued on November 12 alongside that update, with general availability planned for November 19, 2026.

  • RC 1 includes fixes typically reserved for the Nov 12 update release, reducing post-GA churn.
  • Expect RC 2 to launch on November 12, 2026, alongside the standard update release.
  • Final GA release is scheduled for November 19, 2026, marking the official production readiness.
  • Test RC 1 now to validate compatibility with upcoming features before the final GA drop.
PostgreSQL News database

PgBouncer 1.26.1 patches auth bypass and DoS flaws

PgBouncer 1.26.1 addresses three critical vulnerabilities, most notably CVE-2026-107350 which allows authentication bypass for SCRAM users. The update also resolves two denial-of-service issues caused by infinite loops triggered by unauthenticated clients via malformed startup parameters and integer overflows. This release is essential for maintaining connection pool security and stability.

  • CVE-2026-107350 fixes SCRAM auth bypass when connecting to non-existent databases
  • CVE-2026-107349 resolves DoS from empty option names in startup parameters
  • CVE-2026-107348 fixes DoS from integer overflow when max_packet_size exceeds default
  • Unauthenticated clients can trigger DoS, so monitor for connection spikes
  • Upgrade immediately to prevent potential privilege escalation to superuser
TRADE-OFFPgBouncer 1.26.1 FixesBefore UpdateSCRAM auth bypass possibleDoS via startup paramsDoS via integer overflowAfter UpdateAuth bypass patchedEmpty option DoS fixedOverflow DoS resolvedvs
Planet PostgreSQL database

PostgreSQL Replication Slots Can Fill Disk If Standby Drops

Setting primary_slot_name on a standby forces the upstream server to retain all WAL files indefinitely. This retention continues until the disk fills up or the standby connection is lost and the slot is not cleaned up. This behavior creates a significant risk of storage exhaustion if replication lag is not actively monitored.

  • Upstream WAL retention is unbounded until disk is full or slot is removed.
  • Monitor replication lag closely to prevent standby catch-up delays.
  • Ensure standby connection stability to avoid orphaned replication slots.
  • Implement automated cleanup policies for inactive or lagging slots.
  • Watch disk usage on primary servers when using persistent replication slots.
HOW IT WORKSDisk Fill Risk Path1Standby drops connection2Primary retains WAL files3WAL accumulation continues4Disk space exhausted5Service outage occurs

This article marks the start of a four-part series reviewing the final CommitFest for the PostgreSQL 19 development cycle. The primary focus of this installment is on query optimization changes, aligning with the QPT training curriculum. As the last major merge window, this period introduces significant performance enhancements that will define the final release.

  • PostgreSQL 19 development cycle concludes with the March 2026 CommitFest.
  • This series is split into four parts due to the volume of critical changes.
  • Part 5.1 specifically targets query optimization and planner improvements.
  • Subsequent parts will cover DBA-specific features and new SQL functions.

The psqlODBC team released version 18.00.0005 to address CVE-2026-109448, a medium-severity vulnerability causing heap memory corruption. The flaw stems from storing bound parameter counts in a signed 16-bit field, which overflows when an application binds more than 32767 parameters. This overflow writes zeros outside the parameter binding memory, potentially crashing the application or corrupting data. All users of versions 08.01.0102 through 18.00.0004 are advised to upgrade immediately.

  • Upgrade psqlODBC to 18.00.0005 to patch CVE-2026-109448 heap corruption
  • Vulnerability triggers when binding >32767 parameters on a single statement
  • Root cause is a signed 16-bit integer overflow for parameter count storage
  • Risk is highest for apps using untrusted input to determine parameter count
  • Affected versions range from 08.01.0102 up to 18.00.0004 inclusive
TRADE-OFFVulnerability TriggerSafe OperationBinds 32767 parameters maxFits signed 16-bit fieldNo memory corruption occursHeap Corruption RiskBinds more than 32767 paramsOverflows signed 16-bit fieldWrites zeros outside memory boundsvs

Devrim Gündüz has rebuilt bigquery_fdw packages for major RPM-based distributions, resolving a critical regression where Python modules failed to import within the extension's interpreter. The update covers RHEL 8/9/10, Fedora 43/44/45, Amazon Linux 2023, and SLES 15/16, restoring functionality to the foreign data wrapper. This fix addresses a long-standing packaging issue that had rendered the extension unusable for users relying on the official repositories. No user action is required beyond standard package updates to apply the corrected binaries.

  • bigquery_fdw is fully restored on RHEL, Fedora, AL2023, and SLES RPM repos.
  • Root cause was Python module import failures in the extension's embedded interpreter.
  • Update packages via yum/zypper to apply the fix; no config changes needed.
  • Affects all users relying on pre-built RPMs for BigQuery connectivity in PostgreSQL.
  • Full technical details and history available in issue #367.
TRADE-OFFBefore and After the FixBroken StatePython modules failed to importExtension interpreter crashedBigQuery connectivity unusableFixed StateImport errors resolvedInterpreter runs correctlyFull functionality restoredvs

LLMs 8

roundup ↗

Amazon SageMaker JumpStart now hosts Meta's Muse Spark Open, a coding-optimized foundation model designed for agentic workflows. Built on a Mixture-of-Experts architecture with 816B total parameters, it maintains efficient per-token compute while supporting a 1M-token context window. The model targets long-running coding agents and multimodal engineering tasks on AWS infrastructure.

  • SageMaker JumpStart adds Meta's Muse Spark Open for enterprise agentic coding workflows.
  • MoE architecture uses 42B active parameters per token out of 816B total.
  • 1M-token context window allows ingestion of entire projects and dependencies.
  • Optimized for long-running agents and multimodal engineering tasks.
BY THE NUMBERSEfficient MoE Architecture42BActive parameters per tokenOut of 816B total parameters

AbridgeKV addresses memory bottlenecks in long chain-of-thought decoding by training models to compress generated text blocks into learned pause tokens. These special tokens hold no output but store the KV cache state of the preceding text, allowing the system to evict the original block's memory. Subsequent generation steps attend to these compressed pause tokens instead of the full history, significantly reducing memory usage without retraining eviction policies.

  • Replaces linear KV cache growth with fixed-size learned pause token embeddings
  • Enables memory eviction of completed reasoning blocks without quality loss
  • Avoids the degradation seen when evicting cache entries from untrained models
  • Pause tokens act as compressed attention anchors for subsequent decoding steps
HOW IT WORKSAbridgeKV Memory Compression Pipeline1Generate reasoning blocks2Compress into pause tokens3Store KV state in tokens4Evict original block memory5Attend to pause tokens

Microsoft intends to deploy Maia accelerators at multi-gigawatt scale by 2027, positioning them as the primary inference backbone for its internal products. The Maia 300 architecture integrates scale-up and scale-out onto a single Ethernet fabric, enabling efficient KV state transfer between prefill and decode workers without external movement. However, industry observers have raised doubts regarding the specific tokens-per-watt efficiency metrics cited in the announcement.

  • Maia 300 merges scale-up and scale-out on one Ethernet fabric to reduce complexity.
  • KV state moves directly between prefill and decode workers, avoiding external bottlenecks.
  • Multi-gigawatt deployments are scheduled for 2027 to power Microsoft's inference needs.
  • Practitioners are scrutinizing the validity of the claimed tokens-per-watt efficiency.

This research compares a non-generative decision model against a frontier LLM for verifying claims in Retrieval-Augmented Generation pipelines. Using the LLM-AggreFact dataset, the study finds both systems are statistically indistinguishable in performance. The non-generative approach offers native probability outputs and typed values without the overhead of text generation.

  • Non-generative verifiers match frontier LLM accuracy for binary claim verification.
  • Eliminates generation costs by returning typed values and probabilities directly.
  • Paired comparison on 495 human-labeled claims shows no statistical difference.
  • Simplifies RAG pipelines by removing prose generation for verification steps.
BY THE NUMBERS495 Claims Verified495Human-labeled claims testedNo statistical difference found vs LLMs

Verdict-MQ addresses the inefficiency of standard cross-encoders that require separate processing passes for each typed question. By using a structured attention mask, the model encodes the input state once while keeping question representations independent and order-invariant. This approach enables simultaneous answers to multiple organizational queries with sufficient probability accuracy for automated action.

  • Single encoding pass replaces multiple cross-encoder calls, reducing latency for batched decisions.
  • Structured attention masks isolate question processing, preventing cross-question interference.
  • Option order invariance is built-in, simplifying prompt engineering and model stability.
  • Verified state retention under truncation ensures consistent feature extraction across cases.
HOW IT WORKSVerdict-MQ Single-Pass Workflow1Encode input state once2Apply structured attention mask3Process questions independently4Return simultaneous answers
GitHub Trending (daily) githubrepos ⚠ unverified date/source

Lightseek introduces TokenSpeed, a C++ LLM engine for agentic workloads

TokenSpeed is a new inference engine targeting production agentic workloads, claiming performance comparable to TensorRT-LLM while maintaining usability similar to vLLM. It utilizes a C++ control plane and Python execution plane, encoding request lifecycles and KV cache management via a compile-time finite-state machine. The system features a pluggable kernel architecture with a fast Multi-head Latent Attention implementation optimized for Blackwell GPUs.

  • Targets agentic workloads with TensorRT-LLM level performance and vLLM-like usability.
  • Uses C++ control plane and Python execution plane for high-performance inference.
  • Enforces safe KV resource reuse via compile-time type systems and finite-state machines.
  • Features a pluggable kernel system including optimized MLA for Blackwell GPUs.
TRADE-OFFTokenSpeed Architecture ContrastPerformance LayerC++ control planeFast MLA kernelsBlackwell GPU optimizedUsability LayerPython execution planevLLM-like interfaceEasy integrationvs
GitHub Trending (daily) githubrepos ⚠ unverified date/source

XERJ: Local AI search with autoindexing and Elasticsearch compatibility

XERJ is a local AI search tool that automatically indexes folders to enable efficient data retrieval for AI agents. By pre-indexing code, docs, logs, and PDFs, it reduces token consumption compared to traditional text processing commands like grep. The system is compatible with Elasticsearch, allowing existing clients to integrate seamlessly for use cases such as RAG, security audits, and reference coding.

  • Autoindexing eliminates manual grep/sed workflows for AI agents
  • Claims 40x token reduction versus traditional text search methods
  • Elasticsearch compatible interface ensures drop-in integration
  • Supports structured retrieval from code, docs, logs, and PDFs
  • Optimized for reference coding and agent memory contexts
BY THE NUMBERSMassive Token Savings with XERJ40xToken reduction vs grepXERJ cuts token usage significantly compared to traditional search

Meta has published the open-weight Muse Spark model on Hugging Face, marking a significant release of frontier multimodal capabilities. The architecture utilizes a mixture-of-experts design to handle complex multimodal tasks efficiently. This release provides engineers with access to advanced open-source models for local deployment and fine-tuning.

  • Meta's Muse Spark is now available as an open-weight model on Hugging Face.
  • The architecture employs a mixture-of-experts strategy for multimodal processing.
  • Enables local deployment of frontier-level multimodal capabilities without API costs.
  • Provides a base for fine-tuning on proprietary enterprise datasets.

AI / ML 2

roundup ↗

Abhisek Goswami explores the convergence of PostgreSQL and CUDA, likening them to twins from different worlds that are now collaborating. The piece discusses how combining PostgreSQL's data organization with CUDA's massive parallel processing capabilities can unlock new performance potential. It highlights the emerging synergy between relational database management and high-performance GPU computing without adding external facts.

  • PostgreSQL and CUDA represent distinct paradigms: structured data vs. massive parallel compute.
  • Convergence allows leveraging GPU acceleration within database workflows.
  • This integration aims to enhance performance for complex, data-heavy operations.
  • Developers should monitor this trend for potential query optimization strategies.
TRADE-OFFPostgreSQL vs CUDA RolesPostgreSQL RoleManages structured dataOrganizes relational infoEnsures data integrityCUDA RoleEnables parallel computeAccelerates heavy tasksBoosts performance speedvs

Researchers introduce PRISM, a framework exposing how language models may execute unsafe tool calls despite textual refusals. The study demonstrates that activation interventions trained on 4-bit quantized (NF4) models effectively transfer to higher-precision versions and multiple languages. This cross-lingual and cross-scale stability allows for robust alignment improvements even with limited scenario data.

  • NF4 quantized models enable stable intervention estimation with very few training scenarios
  • Activation directions trained on 5 languages transfer effectively to held-out Arabic
  • Framework reveals hidden vulnerabilities where models refuse textually but execute tools
  • Cross-lingual transfer offers a robust pathway to improve model alignment safety
TRADE-OFFPRISM: Hidden Tool RefusalsTextual OutputRefuses unsafe tool callsSafe for userInternal ActivationExecutes unsafe toolsHidden vulnerabilityvs

Agentic AI 7

roundup ↗

Instagram Direct migrated its Android UI from the legacy View system to Jetpack Compose, establishing an AI-native codebase optimized for agent consumption. This structural shift halved the volume of UI code and reduced token costs per AI agent session by 33%. The move prioritizes code clarity and maintainability to lower the overhead of automated development workflows.

  • Migrating to Jetpack Compose creates an AI-native codebase easier for agents to parse and modify.
  • UI code volume decreased by 50%, significantly reducing the context window required for AI tasks.
  • Token costs per AI agent session dropped by 33%, improving the economics of AI-assisted dev.
  • Modern declarative UI frameworks offer tangible ROI when integrated into AI coding pipelines.

Brendan O’Leary analyzes real-world AI adoption patterns derived from massive usage datasets to argue that building developer trust is more critical than chasing model benchmarks. The presentation outlines a four-stage adoption ladder and identifies specific failure points in context construction, multi-model routing, and feedback loops. This analysis provides engineering leaders with a framework for successfully scaling agentic workflows in production environments.

  • Prioritize developer trust over raw model benchmark scores when designing AI agents.
  • Map adoption progress using the four-rung ladder to identify current maturity levels.
  • Audit context construction processes as a primary source of agent failure.
  • Implement robust multi-model routing strategies to handle complex task distribution.
  • Design closed-loop feedback mechanisms to continuously improve agent reliability.

Researchers introduce RealtimeBench, a benchmark with 180 tasks across six game types that evaluate LLM agents while environments remain active during inference. The study reveals that models optimized for accuracy often fall behind faster models when latency causes actions to arrive too late in dynamic settings. To address this, the paper proposes TORSI, a two-timescale approach where a slow teacher corrects errors in paused simulations to generate reusable instructions for a fast student agent.

  • RealtimeBench tests agent performance in continuously running environments, exposing latency-sensitive failures.
  • High-accuracy models may underperform faster alternatives when real-time constraints are enforced.
  • TORSI uses a teacher-student framework to decouple error correction from real-time execution.
  • Slow offline self-improvement generates instructions that enable fast online inference without teacher calls.
  • This approach balances reasoning depth with the speed requirements of live interactive tasks.
BY THE NUMBERSRealtimeBench Task Volume180Tasks in new benchmarkCovers six game types for agent evaluation

Research identifies a fragility in self-improving agents where the policy model and skill bank co-evolve but drift apart post-deployment. Current evaluation metrics only test against the final static skill bank, ignoring the reality that skills may be updated more frequently than the policy is retrained. The study demonstrates that this misalignment causes performance degradation due to cooperative acceptance rules that fail to account for skill drift.

  • Standard evaluations are blind to deployment-time skill drift in self-improving agents.
  • Policy models become fragile when skills are rewritten or removed without retraining.
  • Cooperative acceptance rules exacerbate failures under skill-policy misalignment.
  • New evaluation protocols must account for dynamic skill bank changes.
  • Practitioners should monitor drift between static policy weights and dynamic skill sets.
TRADE-OFFStatic vs Dynamic EvaluationCurrent MetricsTests against final static…Ignores deployment-time…Blind to policy driftRealitySkills update more frequently…Policy becomes fragile…Cooperative rules fail…vs

Long-horizon LLM agents often fail because context compaction mixes environmental facts with compressor reasoning, making them indistinguishable. Analysis shows 83% of failures stem from actions based on unsupported summary entries. The authors propose Source-Judged Compaction, a training-free method that scores summary entries to filter out unsupported claims.

  • Compaction prompts inject reasoning that agents mistakenly treat as environmental facts.
  • 83% of agent failures trace back to executing actions without environment support.
  • Source-Judged Compaction is a training-free post-processing step for better accuracy.
  • This approach prevents hallucinated actions by scoring entry validity before execution.
BY THE NUMBERSFailure Rate from Compaction83%Failures from unsupported actionsStemming from mixed context compaction reasoning

Researchers analyzed 1,514 long-horizon tasks across five benchmarks to evaluate three context-engineering techniques for data agents: semantic layers, orchestration, and compaction. The study examined seven LLMs to determine how these techniques impact accuracy, cost, and agent behavior. Results indicate that without these techniques, agents fall into three distinct behavioral groups, including investigators and premature responders.

  • Context-engineering techniques significantly alter agent accuracy and cost efficiency.
  • Semantic layers, orchestration, and compaction are most effective when combined.
  • Agents without these techniques exhibit unstable behaviors like premature answering.
  • Behavioral analysis reveals distinct agent archetypes in long-horizon tasks.
BY THE NUMBERSTasks Analyzed In Study1,514Long-horizon tasks evaluatedAcross five benchmarks to test context engineering

Amazon MWAA now integrates with the Agent Toolkit to support AI coding assistants via four specific skills: authoring, debugging, testing, and upgrading workflows. These tools allow engineers to use natural language to generate DAGs with dependencies and error handling, or interact directly with the environment for maintenance. The feature is compatible with both Provisioned and Serverless MWAA environments.

  • AI assistants can now generate working DAGs from plain language descriptions.
  • Four distinct skills cover authoring, debugging, testing, and upgrading.
  • Reduces manual effort in building and maintaining data pipelines.
  • Compatible with both MWAA Provisioned and Serverless environments.
HOW IT WORKSMWAA AI Agent Skills1Author workflows2Debug issues3Test logic4Upgrade systems

Automation / DevOps / IaC 8

roundup ↗

Chainguard is releasing two beta tools designed to secure the lifecycle of code generated by AI agents and developers. Chainguard Workspaces offers remote development environments built on hardened microVMs to isolate execution. Complementing this, Chainguard Checks integrates continuous integration directly into the development loop to validate output immediately.

  • AI coding workflows now have dedicated isolation via hardened microVMs in Workspaces.
  • CI/CD shifts left with Checks, embedding validation directly into the dev loop.
  • Both tools target the growing risk of compromised code from AI generation.
  • Products are currently in beta, announced at the Assemble London event.

Spring Authorization Server is now integrated into Spring Security 7, requiring only a version bump for migration. The update introduces server-side support for DPoP and RFC 8693 Token Exchange to enable sender-constrained tokens. Developers must explicitly call .dPoP() in version 7.1 to enforce binding, otherwise it remains inactive by default.

  • Spring Authorization Server is now part of Spring Security 7 under the same Maven coordinates
  • Enable DPoP explicitly via .dPoP() in Spring Security 7.1 to enforce token binding
  • RFC 8693 Token Exchange is supported for service-to-service and agentic communication
  • Combined DPoP and Token Exchange provide narrowed, sender-constrained access tokens

AWS has generally available the Durable Execution SDK for Go, allowing developers to build long-running, resilient workflows directly in Go. The SDK automatically checkpoints progress and pauses execution for up to a year while waiting for external events, eliminating the need for custom tracking logic. This supports complex scenarios like infrastructure automation, deployment rollouts with approval gates, and AI pipelines requiring human review.

  • Native Go SDK for Lambda durable functions removes custom progress tracking overhead
  • Supports long-running workflows with automatic checkpointing and up to one year pause
  • Ideal for infrastructure automation, approval gates, and AI model pipelines
  • Extends Lambda's event-driven model with built-in resilience and state management
HOW IT WORKSLambda Durable Execution Flow1Start long-running workflow2Auto-checkpoint progress3Pause for external events4Resume when ready

AWS has enhanced CloudWatch Pipelines with conditional log routing and chained parsers to improve telemetry processing. Users can now evaluate processed fields to send events to specific log groups based on criteria like severity or source. This allows for granular control over retention policies and access controls without managing underlying infrastructure.

  • Route logs to different groups based on evaluated fields like severity or source.
  • Apply chained parsers to handle nested log formats within a single pipeline.
  • Separate telemetry to enforce distinct retention and access policies per group.
  • Fully managed service handles ingestion, transformation, and routing automatically.
HOW IT WORKSCloudWatch Pipeline Steps1Ingest raw telemetry logs2Apply chained parsers3Evaluate conditional fields4Route to log groups
Planet PostgreSQL database

pgAdmin moves build farm from Jenkins to GitHub Actions

Dave Page details the migration of pgAdmin’s decade-long Jenkins build infrastructure to GitHub Actions. The legacy Jenkins setup handled packaging for all major platforms and release distribution but suffered from opaque configuration and single-point knowledge dependency. The new workflow aims to improve visibility and maintainability by leveraging GitHub Actions.

  • pgAdmin build pipeline migrates from Jenkins to GitHub Actions
  • Legacy Jenkins config was opaque and known only to Dave Page
  • New system improves visibility and reduces single-point dependency
  • Covers Debian, RHEL, Windows, macOS, Python wheels, and Helm charts

Grafana Labs released Tempo 3.1, the first minor update to the 3.0 architecture, introducing query-based trace redaction and sampling-aware metrics. Operators can now redact traces using TraceQL queries instead of managing static trace ID lists. The release also adds TLS and additional SASL mechanisms to the Kafka client and includes an experimental query-time hint to correct TraceQL metrics for sampled data.

  • Redact traces via TraceQL queries instead of maintaining static trace ID lists.
  • Kafka client now supports TLS and additional SASL mechanisms for better security.
  • Experimental hint corrects TraceQL metrics to account for sampled data accurately.
  • First minor release building on the stable 3.0 architecture foundation.

AWS Resilience Hub now leverages the AWS DevOps Agent to automate the review of failure mode assessments and resilience test results. When a resilience test is executed, the agent observes the process and returns a structured analysis of the outcome. This integration allows platform and SRE teams to efficiently identify findings and implement mitigations directly within the console.

  • Resilience tests now trigger automated DevOps Agent investigations for structured feedback.
  • Teams can review failure mode assessments and apply mitigations in one workflow.
  • Generative AI aids in analyzing dependency failures and testing outcomes.
  • Centralizes resilience posture reporting for organization-wide visibility.
HOW IT WORKSAutomated Resilience Analysis Workflow1Execute resilience test2DevOps Agent observes process3Generate structured analysis4Identify findings and mitigations5Apply fixes in console

Amazon Application Recovery Controller's Region switch now supports four new orchestration capabilities to improve multi-Region failover. Users can execute AWS Systems Manager Run Command on managed instances, pass payloads to custom Lambda actions, verify service quota parity, and wait for target group health before scaling compute. These features allow for more granular control and validation during regional impairment events.

  • Run Command execution block enables automated script execution on managed instances during failover.
  • Lambda custom actions now support input payloads for dynamic configuration during recovery.
  • Service quota parity checks ensure target region capacity matches source requirements.
  • Wait for target group health feature prevents premature scaling until instances are ready.
  • Plan evaluation validates command documents and IAM permissions before failover execution.
CHECKLISTWhat matters hereRun Command execution block enables automated script execution on…Lambda custom actions now support input payloads for dynamic…Service quota parity checks ensure target region capacity matches…Wait for target group health feature prevents premature scaling until…Plan evaluation validates command documents and IAM permissions…

AWS 6

roundup ↗

AWS has extended its Transform tool for full-stack Windows modernization to support deploying converted Aurora PostgreSQL databases across regions in seven additional AWS Regions. Users can now upload SQL Server DDL files and explicitly set a target region for the resulting Aurora cluster during the transformation plan. The workflow continues to handle dependent .NET application updates, including connection strings and data-access calls, to ensure PostgreSQL compatibility.

  • Cross-region deployment for converted Aurora PostgreSQL is now available in 7 new AWS Regions.
  • Upload SQL Server DDL files and specify a target region for the modernized database cluster.
  • Automated handling of .NET app updates, including connection strings and ADO.NET/EF calls.
  • Improves data residency, latency, and disaster recovery options for SQL Server modernization.
BY THE NUMBERSNew Regions for Aurora PostgreSQL7New AWS Regions with supportCross-region deployment for converted Aurora PostgreSQL

AWS has extended Web Search availability on Amazon Bedrock AgentCore to US East (Ohio), US West (Oregon), Asia Pacific (Sydney), and AWS GovCloud (US-West). This fully managed tool allows AI agents to ground their responses in current web data for improved accuracy in research and summarization tasks. The expansion enables lower latency by processing data closer to end users and supports government workloads in meeting specific compliance and data residency mandates.

  • Web Search is now live in US East (Ohio), US West (Oregon), Asia Pacific (Sydney), and GovCloud (US-West).
  • Agents gain access to real-time web grounding, enhancing accuracy for QA and summarization workflows.
  • Reduced latency is achieved by retrieving information closer to the application and user location.
  • GovCloud availability ensures compliance for government workloads with strict data residency requirements.
BY THE NUMBERSNew Regions for Bedrock Web Search3New regions addedOhio, Oregon, Sydney plus GovCloud

Amazon DynamoDB Streams now accepts a specific timestamp to start reading records, moving beyond the previous limitation of starting only from the oldest retained entry or new writes. This new AT_TIMESTAMP shard iterator type allows consumers to jump directly to a point in time, eliminating the need to process large volumes of historical data to reach a specific offset. The feature integrates with the Amazon Kinesis Client Library via the DynamoDB Streams Kinesis adapter for seamless implementation.

  • Resume stream consumption from an exact point in time rather than scanning from the beginning of the retention window.
  • Use AT_TIMESTAMP shard iterator to skip irrelevant historical records during recovery or debugging scenarios.
  • Integrates with Kinesis Client Library (KCL) using the DynamoDB Streams Kinesis adapter.
  • Reduces latency and cost when replaying data for auditing or error recovery within the 24-hour retention period.
THE SHIFTPrecise Stream Replay24 hoursOLD SCAN WINDOW24 hoursNEW TARGET TIMEJump to exact timestamp instead of scanning back
AWS Database Blog awsdatabase ↺ since 10-13

AWS guides CLR migration to Lambda for SQL Server 2025 on RDS

Upgrading Amazon RDS for SQL Server to 2017 or later enforces CLR strict security, rendering existing user-defined CLR assemblies unusable. To preserve custom logic without native T-SQL equivalents, AWS recommends migrating these components to AWS Lambda. The updated architecture invokes Lambda functions via sp_invoke_external_rest_endpoint through Amazon API Gateway.

  • CLR assemblies break on RDS SQL Server 2017+ due to strict security enforcement.
  • Migrate legacy CLR logic to AWS Lambda to maintain functionality.
  • Use sp_invoke_external_rest_endpoint to call Lambda from SQL Server 2025.
  • Amazon API Gateway acts as the intermediary layer for the invocation.
AWS Database Blog awsdatabase ↺ since 10-13

AWS RDS SQL Server Adds Automated Blocking and Query Alerts

AWS has introduced a serverless mechanism to detect blocking chains and long-running queries on Amazon RDS for SQL Server. The solution leverages Lambda, CloudWatch, and SES to identify root blockers and dispatch HTML email notifications. This capability is available at a low estimated cost of approximately $2.57 per month.

  • Detects blocking chains and identifies the root blocker automatically
  • Sends HTML email alerts via Amazon SES for immediate visibility
  • Serverless architecture reduces operational overhead
  • Low cost entry at ~$2.57/month for monitoring capabilities
AWS Database Blog awsdatabase ↺ since 10-14

AWS Adds Cost Monitoring for Aurora DSQL via CloudWatch and Console

Amazon Aurora DSQL scales compute and storage without a fixed instance cap, making cost visibility critical. The blog details using the native console panel and CloudWatch alarms to track hourly DPU spend. Users can also automate alarm deployment using AWS CloudFormation templates for consistent governance.

  • Aurora DSQL lacks fixed instance ceilings, so DPU and storage costs can scale unpredictably.
  • Use the built-in Usage and cost panel in the console for immediate visibility into spend.
  • Set up CloudWatch alarms to trigger on hourly DPU spend thresholds for proactive control.
  • Deploy alarm configurations as code via AWS CloudFormation to ensure fleet-wide consistency.

Oracle Ecosystem 1

roundup ↗

Oracle Database@AWS now allows advertising aggregate and default (0.0.0.0/0) routes when peering VPCs with ODB networks. This change eliminates the need to manually advertise individual CIDRs for every connected network or Transit Gateway attachment. Customers can now simplify network operations by using a single route to cover all reachable networks.

  • Simplifies ODB peering by allowing aggregate or default route advertisement
  • Removes requirement to list individual CIDRs for each connected network
  • Reduces configuration overhead when extending VPCs or on-prem links to ODB
  • Supports connectivity via AWS Transit Gateway with broader route ranges
TRADE-OFFODB Peering SimplifiedBefore: Manual ListingList every individual CIDRHigh configuration overheadComplex for many networksAfter: Aggregate RoutesUse single default routeSimplify network operationsSupports Transit Gateway broadlyvs
↑