Database Design

191 posts

cloudflareApr 16, 20262 min readCurated summary

Deploy Postgres and MySQL databases with PlanetScale + Workers

Cloudflare and PlanetScale are integrating more closely so developers can create and manage PlanetScale Postgres and MySQL databases from the Cloudflare dashboard and API. The integration connects these databases to Workers through Hyperdrive, providing connection pooling, query caching, and simplified configuration. Cloudflare billing for new PlanetScale databases is planned for next month, while existing setups remain billed through PlanetScale. ## Postgres and MySQL for Workers - Developers can use either PlanetScale Postgres or Vitess-based MySQL for Worker applications. - Postgres supports a broad ecosystem of tools and extensions such as `pgvector` for AI-oriented vector search. - After connecting a PlanetScale account, users can create databases from the Cloudflare dashboard. - A Hyperdrive binding in `wrangler.jsonc` connects a Worker to the database: ```json { "hyperdrive": [ { "binding": "DATABASE", "id": "<AUTO_CREATED_ID>" } ] } ``` - Workers can then use standard clients such as the Node.js `pg` package and access the connection string through `env.DATABASE`. ## PlanetScale’s Developer Experience - Cloudflare selected PlanetScale for its performance, reliability, and support for both Postgres and MySQL. - PlanetScale features include: - Query insights - Usage and cost breakdowns - Database branching for safer schema and code changes - Agent-assisted SQL performance improvements - Cloudflare users receive the standard PlanetScale experience and pricing, including all available features. - PlanetScale Postgres starts at $5 per month for a single node. ## Reducing Latency with Workers Placement - Workers normally execute close to the incoming user request, which can increase latency when accessing a centralized database. - Developers can configure explicit placement so the Worker runs near the database’s primary region: ```json { "placement": { "region": "aws:us-east-1" } } ``` - Cloudflare plans to automatically determine placement based on the PlanetScale database location, potentially reducing database access latency to single-digit milliseconds. ## Billing and Availability - PlanetScale databases can already be created or connected through the Cloudflare dashboard. - Until the billing integration launches, databases continue to be billed through PlanetScale. - Starting next month, new databases can be billed directly to a Cloudflare self-serve or enterprise account. - Cloudflare credits, startup-program benefits, and committed spend may also apply toward PlanetScale database costs. The integration is intended to give Workers developers a unified platform for globally deployed applications, with flexible SQL storage, optimized database connectivity, and eventually centralized Cloudflare billing.

Database Design Cloudflare PostgreSQL Mysql+3

cloudflareApr 16, 20263 min readCurated summary

Artifacts: versioned storage that speaks Git

Artifacts is a distributed, versioned filesystem designed for AI agents and other high-volume compute environments. It creates repositories programmatically while remaining compatible with standard Git clients, enabling isolated repositories for agent sessions, sandboxes, and large numbers of forks. Cloudflare argues that Git’s familiar data model—commits, history, diffs, and branching—can serve as a general-purpose state-management primitive beyond traditional source control. ## A Git-Compatible Filesystem for Agents - Artifacts repositories can be created through the Workers API or REST API. - Applications receive a Git remote and authentication token, allowing agents to clone and use repositories with ordinary Git commands. - Repositories can be created dynamically for: - Individual agent sessions - Sandbox instances - Large-scale forked environments - Non-Git clients such as Workers, Lambda functions, and Node.js applications can use the API directly or language-specific SDKs. - Existing repositories can be imported from sources such as GitHub, then independently forked for isolated or read-only work. ## Why Git Fits Agent Workflows - Most AI coding agents already understand Git, including common workflows and edge cases. - Git’s object and commit model works well for storing: - Source code and configuration - Session prompts and agent history - Other large collections of small, versioned data - Git provides built-in capabilities for: - Tracking state over time - Reverting changes - Comparing versions - Forking from historical points - Using Git avoids requiring agents to learn a new protocol, CLI, or specialized tool. ## Beyond Source Control - Artifacts can persist an entire agent session’s filesystem and history without requiring dedicated block storage. - Cloudflare uses per-session repositories to: - Restore sandbox state - Share sessions with other people - Time-travel through both prompts and filesystem changes - Fork a session from any point for collaboration or debugging - The same semantics can support non-code data, such as customer-specific configuration that needs rollback, cloning, or diffing. - Cloudflare expects non-Git use cases to be as important as conventional repository workflows. ## Implementation on Cloudflare - Artifacts are built on Durable Objects, which provide isolated, stateful compute capable of supporting millions of repository instances. - The system uses an in-house Git implementation written in Zig and compiled to WebAssembly for Cloudflare Workers. - The implementation was designed to be: - Small - Broadly Git-compatible - Extensible for features such as notes and Git LFS - Efficient in a Workers environment Artifacts is currently available in private beta for paid Workers customers, with a public beta planned for early May. It is intended as a practical way to give agents and applications disposable, persistent, and fully versioned environments without abandoning the Git ecosystem.

Database Design TypeScript Cloudflare Workers Git+4

tossApr 16, 20265 min readCurated summary

Extending Real-time Ad Frequency Capping Aggregation to One Week with Apache Flink + RocksDB Tuning

The post describes Toss’s expansion of real-time advertising frequency-capping from short Flink windows to periods of up to seven days. The new system provides accurate sliding counts from one minute to seven days through a single Redis lookup, while treating Flink state as the authoritative source and Redis as its projection. The migration addressed architectural complexity, backfill consistency, and distinct RocksDB bottlenecks across three specialized Flink applications. ## Frequency Capping and Its Business Impact - Frequency capping controls how many times an individual user sees an advertisement. - Incorrect counts can: - Waste an advertiser’s budget through excessive exposure. - Prevent valid impressions when the system believes a limit has already been reached. - Different products require different windows, such as: - Three impressions per day. - One impression over the previous seven days. - The target system therefore needed accurate, real-time sliding counts from one minute through seven days. ## Limitations of the Previous Batch-Oriented System The original architecture combined three Airflow-managed layers: - **Head** - Stored current-day and previous-day events in Redis through a Spring Kafka consumer. - Updated counts immediately per event. - **Mid** - Used daily Spark jobs to pre-aggregate data from D-2 through D-7. - **Tail** - Added hourly correction data around the boundary between Head and Mid. - Airflow workflows ran approximately 75 times per day. At serving time, the API could perform up to four Redis lookups and combine the results. - This structure was difficult to maintain because of the dependencies and boundary conditions between Head, Mid, and Tail. - Time-based truncation made precise event-level sliding windows difficult. - The architecture remains useful for longer windows such as 30 days and fixed daily aggregates, especially when data exceeds Kafka retention and must be recovered from batch storage. - Extending the existing short-window Flink system was chosen to simplify serving and reduce DAG complexity. ## Three Flink Applications Rather than place all windows in one Flink job, the team split processing into three applications with shared code but independent RocksDB configurations: - **Minutes** - Handles one- to 30-minute windows. - Frequent event expiration creates heavy write traffic. - Its main concern is RocksDB Write Buffer Manager pressure and resulting Write Stalls. - **Hours** - Handles windows up to 12 hours. - Maintains many more advertisement IDs in state. - Filter Block Cache misses can saturate CPU. - Redis synchronization requires an O(N) scan over advertisement IDs in each window. - Filter Block tuning and additional managed memory are important. - **Days** - Handles the largest state volume. - A seven-day window can produce approximately 68 GB of live SST files and 220–230 GB savepoints. - Checkpoint I/O becomes the primary bottleneck, motivating a Flink Changelog design. Separating the applications allowed each workload’s RocksDB and runtime bottlenecks to be optimized independently without affecting the others. ## Backfill and Catch-up Architecture The most difficult migration problem was maintaining correctness at the transition point between historical data and live processing. - **Backfill** - Loads seven days of historical events. - Only increments counts. - Does not register expiration timers. - Synchronizes the initialized values to Redis once and then finishes. - **Catch-up** - Re-reads historical events from Kafka. - Rebuilds both counts and expiration timers. - Begins writing to Redis after reaching the historical scan end. - Enables each window only after sufficient lookback data has been reconstructed. The two phases cannot safely share one pipeline: - Backfill must only add historical counts. - Live or catch-up processing must both add new events and subtract events that leave the sliding window. - If expiration timers ran while backfill was incomplete, decrements could occur before all historical increments had been applied, producing incorrect results. - Flink batch mode was rejected because state is discarded when the job finishes. - A Spark and Hive-based approach was also rejected because it would introduce additional systems and complicate the single-source-of-truth model. Separate Kafka consumer groups were required so that backfill offsets would not cause catch-up events to be skipped. ## State as the Single Source of Truth - Flink state stores the authoritative aggregate. - Redis is treated only as a serving projection. - If Redis becomes inconsistent, it can be reconstructed from Flink state. - This design preserves correctness during failures, restarts, and Redis resynchronization. ## Maintaining Transition Consistency Three mechanisms were combined to make the backfill-to-catch-up boundary reliable: - **Redis write condition** - Writes are based on each event’s `eventTime` being after the backfill completion point. - Using the global watermark directly could block all writes because one slow or idle partition can hold back the watermark. - **`withIdleness` set to 60 seconds** - Excludes inactive Kafka partitions from watermark progression. - A longer timeout avoids falsely marking a partition idle just before a bounded source emits `MAX_WATERMARK`. - **Timer state TTL** - Must exceed the sliding-window expiration period. - If the timer fires after its associated state has expired, `timerState.get()` returns null and the decrement is skipped. - This would leave counts artificially high after delays or recovery. - The state is manually cleaned up after timer processing. ## RocksDB and Flink Runtime Tuning Once the system was serving real-time results, operational metrics exposed different bottlenecks in each application. - The minutes application initially experienced RocksDB Write Stalls caused by pressure on the shared Write Buffer Manager. - RocksDB first stores writes in MemTables and flushes them into SST files organized across levels L0–L6. - Flink maps managed state types such as `MapState` and `ValueState` to separate RocksDB Column Families. - Because multiple Column Families share the Write Buffer Manager’s memory budget, write-heavy workloads require careful tuning of RocksDB memory and write paths. - The hours and days applications require different optimizations focused on cache misses, CPU usage, checkpoint I/O, and level management. ## Practical Conclusion For real-time frequency capping, a unified Flink-based design can simplify serving and improve sliding-window accuracy, but long windows should not automatically be combined with short ones in a single job. Separate applications, state-as-SSOT, distinct backfill and catch-up pipelines, and workload-specific RocksDB tuning are essential for maintaining correctness and operability at scale.

Database Design Redis Apache Flink Airflow+3

cloudflareApr 15, 20263 min readCurated summary

Project Think: building the next generation of AI agents on Cloudflare

Project Think is Cloudflare’s next-generation Agents SDK for building persistent, scalable AI agents. It combines durable execution, sub-agents, persistent sessions, sandboxed code execution, and runtime-created extensions, while allowing developers to use individual primitives or an integrated Think base class. Its central argument is that agents should run as durable, one-to-one infrastructure rather than ephemeral processes on laptops or permanently running servers. ## Why Agents Need a New Foundation - Coding agents increasingly act as general-purpose assistants by reading context, writing and executing code, observing results, and iterating. - Existing agents are limited by: - Dependence on a laptop or costly VPS - Fixed costs while idle - Manual installation, updates, identity, and secret management - Unlike traditional applications, agents are typically one-to-one: each user, task, or conversation may require a distinct agent. - Supporting millions of concurrent agents with always-on containers would be economically impractical. ## Project Think’s Core Primitives Project Think introduces: - Durable execution through fibers, including checkpointing, crash recovery, and automatic keepalive - Isolated sub-agents with independent SQLite databases and typed RPC - Persistent, searchable sessions with message trees, branching, and compaction - Sandboxed code execution using Dynamic Workers, codemode, and runtime npm resolution - An execution ladder spanning workspaces, isolates, npm packages, browsers, and sandboxes - Self-authored extensions that let agents create tools dynamically ## Long-Running Agents with Durable Objects - Each agent is implemented as a Durable Object with: - A stable identity - Persistent SQLite-backed state - Message-based wake-up - Automatic hibernation when idle - Agents can resume after HTTP requests, WebSocket messages, alarms, or inbound email. - Hibernated agents consume no compute, allowing many more agents than an always-on VM or container model. - Durable Objects provide automatic routing, recovery, and per-agent state without separately managed load balancers, databases, or process supervisors. - For example, 10,000 agents active only 1% of the time require capacity for roughly 100 active agents rather than 10,000 continuously running instances. ## Durable Execution with Fibers - Long LLM calls and multi-step workflows can be interrupted by deployments, restarts, or resource limits. - `runFiber()` makes a function invocation durable by: - Registering it in SQLite before execution - Allowing progress to be checkpointed with `stash()` - Recovering interrupted work through `onFiberRecovered` - Agents can save intermediate findings, resume from the latest checkpoint, and broadcast progress to clients. - The SDK automatically keeps the agent alive while a fiber runs. - `keepAlive()` and `keepAliveWhile()` support active work lasting minutes or longer, such as CI pipelines, design reviews, and video generation. Project Think’s recommendation is to treat agents as persistent, addressable infrastructure: use the low-level primitives for customization, or adopt the Think base class for a faster, integrated starting point.

Database Design Durable Objects Sqlite Agents Sdk+4

cloudflareApr 15, 20263 min readCurated summary

Introducing Agent Lee - a new interface to the Cloudflare stack

Agent Lee is Cloudflare’s new in-dashboard AI assistant, designed to replace complex navigation with natural-language interaction across the Cloudflare platform. It can inspect account data, troubleshoot issues, and—when explicitly approved—make changes or deploy resources. Built on Cloudflare’s own infrastructure, it combines sandboxed code execution, permission controls, and generative UI to provide an interactive way to manage real accounts. ## A Natural-Language Interface to Cloudflare - Agent Lee understands account resources such as Workers, zones, DNS settings, and error rates. - Users can ask it to: - Identify the top error messages for a Worker. - Diagnose access problems involving a `www` prefix. - Enable Cloudflare Access for a domain. - Create an R2 bucket and connect it to a Worker. - It can retrieve account-specific context, use the appropriate tools, and present results through charts and other visualizations. - The beta reportedly serves about 18,000 daily users and performs nearly 250,000 tool calls per day across services including DNS, Workers, SSL/TLS, R2, Registrar, Cache, Cloudflare Tunnel, and API Shield. ## Codemode and Sandboxed Execution - Instead of exposing raw MCP tool definitions to the model, Agent Lee uses Codemode. - The model writes TypeScript that calls a generated API, which is intended to improve accuracy and support multi-step operations in a single script. - Generated code runs through a Cloudflare MCP server and a Durable Object acting as a credentialed proxy. - The Durable Object: - Classifies operations as reads or writes by inspecting the method and request body. - Proxies read operations directly. - Blocks write operations until the user explicitly approves them. - Keeps API keys out of generated code and injects credentials server-side. ## MCP Permissions and User Approval - Agent Lee connects to Cloudflare’s MCP server through: - A search tool for querying API endpoints. - An execute tool for running code that performs API requests. - Any operation that changes the account must pass through an elicitation step. - Approval is an enforced permission boundary rather than merely a confirmation-oriented interface feature. - Agent Lee cannot bypass the approval gate before executing writes. ## Built on Cloudflare’s Public Stack - Agent Lee uses the same building blocks available to Cloudflare customers: - Agents SDK - Workers AI - Durable Objects - Cloudflare’s MCP infrastructure - Cloudflare developed and tested the system in production against real accounts. - The company positions this approach as a way to identify platform limitations and validate patterns that other developers can reuse. ## Generative UI - Agent Lee supplements text responses with dynamically generated interface components. - Questions about traffic can produce interactive line charts rather than plain numerical summaries. - An adaptive grid lets users reserve space for new UI blocks by dragging across the interface and describing what they want. - Supported components include: - Tables - Interactive charts - Architecture maps - Other dynamic visual blocks - The result is intended to turn conversation history into an evolving operational dashboard. ## Quality and Safety - Elicitations are used whenever Agent Lee needs to perform a non-read action, requiring explicit approval in the interface. - Cloudflare also evaluates the system’s: - Conversation success rate - Information accuracy - Because the product remains in beta, users may encounter limitations or edge cases as its reliability and performance continue to improve. Agent Lee’s central promise is to make Cloudflare operations conversational without removing control. Its most important design choice is the combination of broad account awareness with a structural approval gate for changes, while its generative UI makes the resulting information and workflows more actionable.

Database Design Cloudflare User Interface TypeScript+4

cloudflareApr 15, 20263 min readCurated summary

Add voice to your agent

Cloudflare’s experimental `@cloudflare/voice` package adds real-time voice to existing Agents SDK applications without requiring a separate voice framework. Voice interactions use the same Durable Object, WebSocket connection, tools, and SQLite-backed history as text interactions. The package provides ready-made STT and TTS integrations while keeping provider interfaces open for alternative speech, telephony, and transport systems. ## Voice Support for Existing Agents - `withVoice(Agent)` enables full conversational voice agents. - `withVoiceInput(Agent)` supports speech-to-text-only features such as dictation and voice search. - React applications can use `useVoiceAgent` and `useVoiceInput`. - Framework-independent clients can use `VoiceClient`. - Built-in Workers AI providers include: - Deepgram Flux for continuous speech-to-text - Deepgram Nova 3 for speech-to-text - Deepgram Aura for text-to-speech - Developers can get started without external API keys. ## Minimal Server and Client Setup - A voice agent extends a class created with `withVoice(Agent)`. - The server configures a transcriber and TTS provider, then implements `onTurn()`. - `onTurn()` receives the user’s transcript and returns the agent’s response. - React clients can display: - Connection status - Interim and finalized transcripts - Conversation messages - Start, end, and mute controls - Non-React applications can connect through `@cloudflare/voice/client`. ## How the Voice Pipeline Works - The browser captures 16 kHz mono PCM microphone audio. - Audio streams over the agent’s existing WebSocket connection. - A continuous STT session remains active for the duration of the call. - The speech-to-text model detects completed utterances and produces stable transcripts. - Each transcript is passed to `onTurn()` for application or LLM logic. - The response is synthesized into audio and streamed back to the client. - Streamed responses can be sentence-chunked so audio begins playing before the full response is complete. - User and agent messages are persisted in the Durable Object’s SQLite database, surviving reconnections and deployments. ## Extensible Provider Architecture - The package is designed not to lock developers into one fixed voice stack. - Small provider interfaces allow speech, telephony, and transport providers to build integrations. - Developers can mix and match components based on their application’s requirements. - Voice therefore becomes another interaction mode for the same stateful agent rather than a separate application architecture. Cloudflare’s approach is best suited to developers who already use the Agents SDK and want to add conversational voice while preserving existing state, tools, persistence, and connection patterns. Since the package is experimental, teams should evaluate provider support and API stability before relying on it in production.

Database Design React Sqlite Speech To Text+3

cloudflareApr 15, 20263 min readCurated summary

Rearchitecting the Workflows control plane for the agentic era

Workflows was originally designed for human-paced events, but autonomous agents now create and manage workflow instances at machine speed. To support this shift, the platform increased its limits substantially and redesigned its control plane for horizontal scalability. The new architecture replaces V1’s account-level bottleneck with distributed components while preserving durable execution, retries, and human-in-the-loop pauses. ## The Shift to Agent-Driven Workloads - Workflows initially handled events such as sign-ups and purchases, typically requiring only one instance per person. - Persistent agents can operate for hours or days and launch dozens of workflows from a single session. - Concurrent agents can create thousands of workflow instances within seconds. - Workflows also serve as durable execution harnesses for agent loops, maintaining progress across failures and supporting asynchronous work. ## Higher Workflows Capacity The platform now supports: - **50,000 concurrent instances**, up from 4,500. - **300 instance creations per second per account**, up from 100. - **2 million queued instances per workflow**, up from 1 million. These increases were driven by observed usage patterns and a redesign of the control plane. ## V1: A Single Account-Level Bottleneck - Each workflow consists of durable, independently retryable steps that can run tasks, wait for events, or sleep until a scheduled time. - SQLite-backed Durable Objects provide execution, coordination, and storage. - An **Engine Durable Object** is created for each workflow instance and handles execution, retries, and sleeping. - A single **Account Durable Object** manages account-wide workflow and instance metadata. - All create, update, and list operations passed through the Account object. - High-volume customers could generate thousands of requests per second as instances started and completed, overwhelming the singleton. - The original rate limits were therefore hard architectural limits rather than adjustable product settings. ## V2: Horizontal Scaling Principles The redesigned control plane is based on several architectural changes: - The instance’s **Engine is now the sole source of truth** for whether that instance exists. - The system verifies that an Engine exists before queuing an instance, avoiding queued instances with no running execution object. - Instance lifecycle and liveness operations are distributed across workflows and regions so they can scale horizontally. - The Account singleton stores only essential metadata and has a bounded maximum number of concurrent requests. - Limits are designed to be flexible and increaseable rather than constrained by one central bottleneck. ## SousChef and Gatekeeper - V2 introduces two central components: **SousChef** and **Gatekeeper**. - SousChef acts as a “second in command” to the Account, taking over work that previously concentrated all workflow and instance management in one Durable Object. - Together, these components are intended to distribute control-plane responsibilities and enable higher creation rates and concurrency. - The migration was performed with live traffic, allowing customers to move to the new architecture without interruption. The redesign aligns Workflows with agentic workloads by moving coordination away from a single account-level Durable Object. Developers running high-volume or highly concurrent agents should benefit from the new limits and a control plane that can continue scaling independently.

Database Design Durable Objects Sqlite Scalability+3

gitlabApr 15, 20263 min readCurated summary

A guide to the breaking changes in GitLab 19.0

GitLab 19.0 is expected to introduce 15 breaking changes, primarily by removing deprecated components and outdated platform support. The most significant effects involve Helm chart networking and bundled services, OAuth authentication, PostgreSQL, Redis, and supported operating systems. Administrators should audit their deployments and complete migrations before upgrading. ## Release and Deployment Windows - **GitLab.com:** Primary breaking-change window is May 4–6, 2026, with a fallback window on May 11–13. - **GitLab Self-Managed:** GitLab 19.0 becomes available May 21, 2026. - **GitLab Dedicated:** Upgrades occur during assigned maintenance windows, with GitLab 19.0 scheduled for the week of June 22, 2026. - Additional changes may roll out outside these windows in exceptional circumstances. ## High-Impact Changes ### NGINX Ingress Replaced by Gateway API - The GitLab Helm chart will use **Gateway API with Envoy Gateway** as its default networking configuration. - Bundled NGINX Ingress reached end-of-life in March 2026. - Existing deployments can explicitly continue using bundled NGINX Ingress until its planned removal in GitLab 20.0. - The change does not affect: - NGINX used by the Linux package. - Deployments using externally managed Ingress or Gateway API controllers. - Administrators should plan migration to Envoy Gateway or another externally managed controller. ### Bundled PostgreSQL, Redis, and MinIO Removed - The GitLab Helm chart and GitLab Operator will no longer bundle Bitnami PostgreSQL, Bitnami Redis, or the forked MinIO chart. - These components were intended for proof-of-concept and test environments, not production. - Deployments using them must migrate to external services before upgrading. - PostgreSQL and Redis bundled with the Linux package are unaffected. ### OAuth ROPC Grant Removed - The Resource Owner Password Credentials OAuth flow will be removed across GitLab.com, Self-Managed, and Dedicated. - ROPC is being eliminated because of security limitations and its removal from OAuth 2.1. - Applications using ROPC must migrate to a supported flow, such as Authorization Code. - After upgrading, ROPC will not work even when client credentials are provided. ### PostgreSQL 17 Becomes Required - PostgreSQL 16 will no longer be supported; PostgreSQL 17 becomes the minimum version. - Single PostgreSQL instances installed through the Linux package may be upgraded automatically during GitLab 18.11. - Cluster deployments and installations that opt out of automatic upgrades require a manual migration. - Administrators should verify sufficient disk space and complete the upgrade before GitLab 19.0. ## Medium-Impact Changes ### Ubuntu 20.04 Packages Discontinued - GitLab will stop publishing Linux packages for Ubuntu 20.04. - GitLab 18.11 is the final release supporting that distribution. - Affected installations must upgrade to Ubuntu 22.04 or another supported operating system first. ### Redis 6 Support Removed - External Redis 6 deployments must migrate to Redis 7.2 or Valkey 7.2. - The Linux package’s bundled Redis is unaffected because it has used Redis 7 since GitLab 16.2. - Migration options vary by provider: - AWS ElastiCache and GCP Memorystore: Redis 7.2 or Valkey 7.2. - Azure: self-host Redis or Valkey on VMs or AKS until managed support is available. - Self-hosted installations: upgrade directly to Redis 7.2 or Valkey 7.2. ### Auto DevOps Builder Image Updated - The CNB builder image used by Auto DevOps changes from `heroku/builder:22` to `heroku/builder:24`. - Pipelines relying on the older image may need testing or configuration updates. GitLab administrators should review the deprecations and upgrade documentation, identify whether their deployment uses any affected components, and complete required migrations before GitLab 19.0.

Database Design Gitlab PostgreSQL DevOps+4

gitlabApr 14, 20262 min readCurated summary

GitLab and Vertex AI on Google Cloud: Advancing agentic development

GitLab is partnering with Google Cloud to combine the GitLab Duo Agent Platform’s lifecycle-wide orchestration with Vertex AI’s managed foundation models and enterprise controls. The integration gives development teams context-aware agents for planning, coding, security, and delivery while keeping workflows within GitLab’s governed system of record. Customers gain model flexibility, stronger governance, and reduced complexity compared with managing disconnected AI tools. ## Agents Across the Software Development Lifecycle - GitLab Duo Agent Platform coordinates specialized agents across planning, development, code review, security, and delivery. - Unlike standalone coding assistants, GitLab agents can access issues, merge requests, pipelines, vulnerabilities, and codebases. - GitLab Duo Planner Agent can analyze backlogs, divide epics into tasks, and support prioritization. - Security Analyst Agent can triage vulnerabilities, explain risks, and recommend remediation priorities. - Built-in flows connect agents into end-to-end processes, reducing manual handoffs. - Agentic Chat provides natural-language access to project context and multi-step reasoning within GitLab. ## Vertex AI as the Model and Infrastructure Layer - Vertex AI supplies the foundation models and related services used by GitLab agents. - Newer models improve reasoning, tool use, and long-context understanding, supporting workloads such as backlog analysis and monorepo security reviews. - Vertex AI Model Garden offers Gemini, third-party, and open-source models, allowing customers to balance performance, cost, and regulatory requirements. - GitLab supports Bring Your Own Model configurations, enabling organizations to use approved providers and gateways. - Vertex AI abstracts LLM hosting, including infrastructure management, security, governance, and model-version delivery. ## Enterprise Governance and Operational Benefits - GitLab’s AI Gateway mediates model access, helping administrators track connections and maintain governance. - Developers remain in GitLab while inference follows existing Google Cloud security and policy controls. - Platform teams can standardize which models support recommendations, analysis, and remediation. - Security teams can manage findings and proposed fixes in the same environment, reducing context switching and unmanaged workflows. - Using Vertex AI through GitLab can align AI usage with existing Google Cloud contracts, controls, and procurement policies. - The approach helps reduce duplicate spending and fragmented “shadow AI” toolchains. ## Practical Outcome for Google Cloud Customers The integration is intended to increase developer productivity without requiring teams to evaluate, host, or manage individual language models. GitLab provides the governed DevSecOps control plane, while Vertex AI supplies scalable, flexible model infrastructure, enabling organizations to adopt more capable agentic workflows while maintaining enterprise security and control.

Database Design Gitlab DevSecOps Software Development Lifecycle+4

awsApr 13, 20263 min readCurated summary

AWS Weekly Roundup: Claude Mythos Preview in Amazon Bedrock, AWS Agent Registry, and more (April 13, 2026) | Amazon Web Services

AWS’s April 13, 2026 roundup centers on improving governance and visibility as organizations move AI workloads into production. Amazon Bedrock added IAM user and role-based cost allocation, while Claude Mythos Preview and the AWS Agent Registry expanded capabilities for cybersecurity and agent management. The week also brought updates across storage, observability, WorkSpaces, and quantum computing. ## Bedrock Cost Allocation - Organizations can tag IAM users and roles with attributes such as team or cost center. - Activated tags appear in Billing and Cost Management, AWS Cost Explorer, and detailed Cost and Usage Reports. - This enables teams to track foundation model inference costs across departments, agents, and tools such as Claude Code on Bedrock. ## Claude Mythos Preview in Amazon Bedrock - Anthropic’s Claude Mythos is available as a gated research preview through Project Glasswing. - The model is designed for advanced cybersecurity work, including: - Finding sophisticated vulnerabilities - Analyzing large codebases - Handling complex reasoning and coding tasks - Access is limited to allowlisted organizations, with priority given to critical internet companies and open-source maintainers. ## AWS Agent Registry - AgentCore’s new registry provides a private catalog for AI agents, tools, skills, MCP servers, and custom resources. - Features include semantic and keyword search, approval workflows, and CloudTrail auditing. - Teams can access it through the AgentCore Console, AWS CLI, SDKs, or as an MCP server from IDEs. - The goal is to improve reuse and governance instead of having teams independently recreate capabilities. ## Other AWS Launches - **Amazon S3 Files:** Exposes S3 buckets as shared file systems with file-system semantics, caching, and high aggregate read throughput. Applications can use file-system and S3 APIs simultaneously without migration or code changes. - **OpenSearch observability:** Adds Managed Prometheus, PromQL support, RED metrics, agent tracing, and OpenTelemetry GenAI semantic conventions for correlating AI execution with logs and traces. - **WorkSpaces Advisor:** Uses generative AI to diagnose Amazon WorkSpaces Personal configuration issues and recommend fixes. - **Amazon Braket:** Adds Rigetti’s 108-qubit Cepheus-1-108Q processor, supporting Braket SDK, Qiskit, CUDA-Q, Pennylane, and pulse-level control. ## Additional Resources and Upcoming Events - AWS highlighted guidance for regional availability monitoring with S3, Bedrock model lifecycle management, memory-intensive Lambda managed instances, and OpenClaw deployment choices. - Kiro is bringing back startup credits, offering eligible companies one year of Pro+ access across three team-size tiers. - The virtual “What’s Next with AWS” event on April 28 will focus on agentic AI and feature AWS, OpenAI, and industry leaders. Organizations adopting AI at scale should prioritize IAM-based cost attribution, centralized agent governance, and lifecycle planning for foundation models.

Database Design PostgreSQL Amazon Bedrock Aws Lambda+4

cloudflareApr 13, 20263 min readCurated summary

Building a CLI for all of Cloudflare

Cloudflare is rebuilding Wrangler into a unified CLI for its entire platform, motivated by the growing role of coding agents in configuring and deploying Cloudflare applications. The technical preview, available as `npx cf` or the globally installed `cf` package, currently covers only a subset of products but is intended to support the full API surface. The effort depends on a new TypeScript-based schema system that can generate consistent commands, configuration, bindings, documentation, and agent-oriented interfaces. ## A CLI for all of Cloudflare - Cloudflare offers more than 100 products and nearly 3,000 HTTP API operations. - Agents increasingly use Cloudflare APIs to: - Build and deploy applications - Configure accounts - Query analytics and logs - Create agents and platforms - Cloudflare aims to expose its products consistently through: - CLI commands - Workers Bindings - SDKs - Configuration files - Terraform - Documentation and OpenAPI schemas - MCP servers and Agent Skills - The new Wrangler technical preview can be tried with: - `npx cf` - `npm install -g cf` - A broader internal version already supports the full Cloudflare API, with ongoing work to make command output useful for both humans and agents. ## A new schema and code-generation pipeline - Existing OpenAPI schemas already generate: - Cloudflare SDKs - The Terraform provider - The Code Mode MCP server - Other interfaces, including Wrangler commands, Workers Bindings, configuration, documentation, and Agent Skills, were previously maintained manually. - Manual synchronization was error-prone and could not scale to Cloudflare’s full product range. - OpenAPI alone is insufficient because it primarily describes REST APIs, while Cloudflare also needs to represent: - Interactive CLI workflows - Multiple local and remote actions - RPC-style Workers Bindings - Agent Skills and related documentation - Cloudflare therefore created a TypeScript schema format containing: - API definitions - CLI commands and arguments - Context required to generate different interfaces - Conventions, linting, and guardrails enforce consistency while allowing the schema to generate OpenAPI and future interfaces. ## Consistency for agents and humans - Agents depend on predictable command names and flags. Inconsistent syntax can cause them to call commands that do not exist. - Cloudflare is enforcing conventions at the schema layer, including: - `get`, never `info` - `--force`, never `--skip-confirmations` - `--json`, never `--format` - Applying these rules across interfaces avoids discrepancies between the CLI, REST APIs, and SDKs. - Wrangler must also clearly distinguish local and remote resources. - This is especially important for D1, R2, and KV, where local simulation and remote bindings can coexist. - Clear defaults and output indicating whether an operation targets local or remote resources help agents avoid modifying the wrong environment. ## Local Explorer for simulated resources - Local Explorer is available in open beta through Wrangler and the Cloudflare Vite plugin. - It lets developers inspect locally simulated: - KV - R2 - D1 - Durable Objects - Workflows - Local resources use the same underlying API structure as Cloudflare’s remote APIs and Dashboard. - Cloudflare’s local development environment runs Workers APIs locally, including D1 backed by SQLite through Miniflare. - Previously, developers had to inspect `.wrangler/state` or use third-party tools to understand local data. - Local Explorer provides an interface showing: - Which bindings are attached to a Worker - What data those bindings contain - It can be opened with the `e` keyboard shortcut and helps developers or agents verify schemas, seed test data, and reset local databases. Cloudflare’s direction is to make Wrangler a consistent, machine-readable interface to the entire platform. The technical preview is early, but the new schema-driven system and Local Explorer establish the foundation for a CLI that is easier for both developers and coding agents to use safely.

Database Design Cloudflare TypeScript Terraform+4

cloudflareApr 13, 20263 min readCurated summary

Durable Objects in Dynamic Workers: Give each AI-generated app its own database

Dynamic Workers make it possible to run AI-generated code securely in lightweight isolates, but disposable execution is not enough for persistent applications. Cloudflare’s Durable Object Facets address this by letting a supervised Durable Object dynamically load an AI-generated Durable Object class with its own SQLite-backed storage. This combines sandboxed, persistent application state with centralized control over provisioning, access, logging, metrics, and billing. ## From Disposable Code to Persistent Apps - Dynamic Workers load code on demand in secure isolates rather than containers. - Isolates start quickly and use little memory, making them suitable for short-lived AI-generated tasks. - Persistent AI-built applications need: - Custom user interfaces - Long-lived state - Secure execution - A remote SQL database could provide storage, but it introduces network latency and additional infrastructure. ## Why Durable Objects Fit - Each Durable Object has: - A globally unique name - One active instance per name - An attached SQLite database stored locally - Local SQLite storage provides extremely low-latency access. - AI-generated applications can therefore use normal Durable Object storage APIs, including key-value and SQL storage. ## Limitations of the Traditional Model - Standard Durable Objects require: - A class extending `DurableObject` - Exporting the class from the Worker - Wrangler configuration to provision storage - A namespace binding for access - This model does not naturally support code loaded dynamically at runtime. - Giving an agent direct control of Durable Object namespaces could also allow uncontrolled object creation and storage use. - A platform needs an intermediary to enforce limits and provide observability, billing, and other operational controls. ## Durable Object Facets - Facets allow a normal, statically configured Durable Object to dynamically instantiate another Durable Object class. - The outer object acts as a supervisor: - Loads the agent’s code as a Dynamic Worker - Selects the exported Durable Object class - Forwards requests or RPC calls - Controls and monitors the application - The dynamically loaded class can directly extend `DurableObject`. - Each facet receives its own SQLite database, separate from the supervisor’s database. - Multiple facets can exist within one Durable Object, each identified by a name and subject to storage limits. ## Example Architecture - An `AppRunner` Durable Object receives incoming requests. - It obtains a facet named `"app"` through `this.ctx.facets.get(...)`. - When the facet starts, the runner: - Loads the Dynamic Worker - Retrieves its exported application class - Instantiates it as the facet - Requests are then forwarded to the dynamically loaded application. - The sample application maintains a request counter using Durable Object storage. Durable Object Facets provide a practical foundation for AI-generated applications that need persistent state without sacrificing isolation or platform governance. They are especially suited to personal or small “vibe-coded” apps, where each application can receive its own storage while the host platform retains control over resource usage and operational policies.

Database Design Cloudflare PostgreSQL Durable Objects+3

gitlabApr 13, 20263 min readCurated summary

GitLab named a 2026 Omdia Universe Leader

GitLab was named a Leader in Omdia’s 2026 Universe for AI-assisted Software Development, IDE-based Tools, ranking among 19 vendors. Its strongest results came from covering the entire software lifecycle—not just code generation—including planning, security, testing, deployment, and operations. The report suggests that AI delivers the greatest productivity gains when automation extends beyond coding into coordinated, governed delivery. ## Omdia’s Broader Evaluation - Omdia expanded its criteria to assess full software lifecycle capabilities. - The report emphasized that faster coding alone can create downstream bottlenecks in: - Code review - Security remediation - Testing - Deployment coordination - Agentic AI was evaluated as a current capability, including: - Autonomous task coordination - Handoffs between specialized agents - Support for teams at different stages of AI adoption - Omdia categorizes vendors as Leaders, Challengers, or Prospects based on capability and strategy/execution. ## GitLab’s Top Scores - **Solution Breadth: 100%** - Covers planning, requirements, development, security, deployment, and issue management in one platform. - Planner Agent and Security Analyst Agent extend AI into sprint planning, vulnerability triage, and remediation guidance. - **Strategy and Innovation: 88%** - Uses end-to-end orchestration and a privacy-first architecture that does not train on private customer data. - Supports multiple models through partnerships with Anthropic, Google, and AWS. - Provides shared context across issues, merge requests, pipelines, and security findings. - **Core Features: 82%** - Offers context-aware code generation, unit and integration testing, security testing, and review prioritization. - Automates CI/CD, GitOps, and pipeline-failure root cause analysis. - The AI Impact Dashboard tracks cycle time, deployment frequency, and productivity effects. - GitLab also received top-tier scores for Extended Features (80%) and Vendor Execution (88%). ## Developers and AI Agents - Teams are increasingly structured around engineers supervising AI agents. - Human responsibilities are shifting toward: - Defining requirements and guardrails - Supervising quality and security - Designing autonomous production pipelines - Connecting business objectives with agentic systems - Automating only code generation provides limited benefit if review, testing, and deployment remain manual. ## Enterprise Readiness - Omdia treated compliance, privacy, and deployment flexibility as baseline requirements for Leader-tier platforms. - GitLab highlights: - SOC 2 and ISO 27001 certification - No training on private customer data for agentic AI - Self-managed, cloud, on-premises, and air-gapped deployment - Support for self-hosted AI models - GitLab Dedicated, including FedRAMP Moderate authorization for government - These capabilities target regulated industries requiring strong data residency, auditability, and governance. GitLab’s central argument is that AI coding speed matters only when the rest of the software delivery lifecycle can keep pace. Engineering teams should evaluate AI platforms by their ability to deliver secure, governed, production-ready software—not merely by how much code they can generate.

Database Design AI Agents CI/CD Gitlab+4

cloudflareApr 12, 20263 min readCurated summary

Welcome to Agents Week

Cloudflare argues that AI agents require a fundamental shift in Internet and cloud infrastructure. Unlike traditional one-to-many applications, agents create unique, ephemeral execution environments for individual users and tasks, making current container-based economics and scaling inadequate. The company positions lightweight V8 isolates, alongside containers and browser support, as the foundation for making agents practical at global scale. ## The Internet Was Built for Applications, Not Agents - Cloud infrastructure evolved during the smartphone era to serve many users through a finite number of application instances. - Microservices, containers, Kubernetes, load balancing, and replication all support this one-to-many model. - Agents differ because an LLM dynamically determines code paths, tool usage, and task duration. ## One User, One Agent, One Task - Each agent may need its own execution environment, filesystem, tools, and state. - Coding agents currently use containers with access to Git, Bash, filesystems, and arbitrary binaries. - As agents spread to assistants, analysts, customer service, and planning tasks, the number of simultaneous environments could grow dramatically. ## The Scale Challenge - If 100 million US knowledge workers used agents at 15% concurrency, infrastructure would need about 24 million simultaneous sessions. - At 25–50 users per CPU, that implies roughly 500,000 to 1 million server CPUs in the US alone. - Multiple agents per person and global adoption would increase demand by orders of magnitude. ## Isolates as Agent Infrastructure - Cloudflare’s Workers platform uses V8 isolates instead of containers. - Isolates start in milliseconds, use only a few megabytes of memory, and provide secure sandboxing. - They can be up to 100 times faster to start and up to 100 times more memory-efficient than containers. - Dynamic Workers can create execution environments on demand, run code, and discard them at a scale of millions per second. - This efficiency could make one-agent-per-user economics viable beyond expensive coding assistants. ## The “Horseless Carriage” Phase - Early agent infrastructure often adapts existing systems instead of using designs built specifically for agents. - Agents use headless browsers to navigate human-oriented websites, though structured protocols such as MCP could provide direct service access. - Many MCP servers simply wrap REST APIs, despite LLMs often being better at writing and executing code than making long sequences of tool calls. - CAPTCHAs and behavioral fingerprinting ask whether a requester is human, while agent systems need identity, authorization, and permission controls. - Full containers are frequently used for tasks that require only a few API calls and a response. ## Supporting Both Old and New Models - Infrastructure transitions rarely happen all at once; technologies such as IPv4/IPv6, HTTP/2/HTTP/3, and TLS 1.2/1.3 coexist. - Cloudflare plans to support existing agent workloads while developing more efficient primitives. - Containers remain important for coding agents that need filesystems, Git, Bash, and arbitrary binaries. - Cloudflare is also expanding container-based sandbox environments and browser-rendering capabilities for services that do not yet support agent-native protocols. Cloudflare’s broader recommendation is to build infrastructure that can serve today’s container-based agents while moving toward lightweight, ephemeral isolates designed for billions of specialized agent sessions.

Database Design Large Language Models Kubernetes Cloudflare Workers+4

netflixApr 10, 20263 min readCurated summary

Evaluating Netflix Show Synopses with LLM-as-a-Judge

Netflix developed an LLM-as-a-Judge system to evaluate show synopses at the scale of its extensive catalog. The system assesses creative quality against expert-defined standards while also examining whether scores predict member behavior. With calibrated prompts, extended reasoning, and consensus scoring, the approach achieves more than 85% agreement with creative writers and can identify potentially impactful synopsis problems before a title launches. ## Defining a Good Synopsis - Synopsis quality is measured in two ways: - **Creative quality:** how well a synopsis follows Netflix’s editorial standards. - **Member feedback:** how the synopsis affects viewing decisions and early engagement. - Strong synopses help members quickly understand and choose titles. - Weak or misleading synopses can cause frustration, abandonment, and reduced viewing. ## Building Expert-Labeled Evaluation Data - Creative experts initially labeled roughly 1,000 diverse synopses. - Three writers scored each synopsis and explained their decisions. - Because the task was subjective, Netflix used eight calibration rounds to improve consistency. - Techniques that increased agreement included: - Replacing 1–4 ratings with binary scores. - Allowing writers to consult previous examples. - Maintaining a searchable taxonomy of recurring errors. - A model-in-the-loop process helped resolve disagreements: - Multiple writers supplied scores. - An LLM aggregated the judgments. - Writers reviewed cases with significant disagreement. - The resulting “golden set” contains about 600 synopses with criterion-level labels and explanations. ## Measuring Member Impact - Netflix uses two behavioral metrics: - **Take fraction:** how often members who see a synopsis start watching the title. - **Abandonment rate:** how often viewers stop shortly after beginning. - These metrics act as short-term proxies for long-term retention and have been validated through A/B testing. - Netflix evaluates whether LLM-generated quality scores can predict these engagement outcomes. ## Criterion-Specific LLM Judges - Initial prompts provide: - Relevant show metadata. - A summary of the applicable quality guidelines. - A request for an explanation followed by a binary score. - A single prompt covering every criterion performed poorly because it overloaded the model. - Separate judges for individual criteria performed better. - Binary outputs make evaluation straightforward using accuracy against the expert-labeled golden set. ## Improving Prompts and Reasoning - Netflix applies Automatic Prompt Optimization to a development set of about 300 examples. - Prompts are then manually refined with LLM assistance. - Performance varies significantly by criterion: prompts work well for areas such as precision but less well for subjective criteria such as clarity. - Inference-time scaling improves difficult judgments through: - **Longer rationales**, which give the model more room to reason. - **Consensus scoring**, which samples multiple judgments and combines their results. ## Tiered Rationales - Longer explanations generally improve accuracy, but they become harder for creative experts to read and audit. - Netflix therefore uses tiered rationales: - The model may reason at length internally. - It produces a concise explanation before the final score. - This approach preserves the benefits of extended reasoning while improving interpretability. - For example, the tone evaluator’s accuracy increased from 86.55% to 87.85% with tiered rationales. Netflix’s approach combines expert standards, calibrated evaluation data, specialized prompts, and inference-time reasoning to scale synopsis-quality review. The practical recommendation is to use LLM judges as carefully aligned evaluators—not generic critics—while validating their scores against both human judgment and real member behavior.

Database Design Llm As A Judge Automatic Prompt Optimization Creative Quality+4