PostgreSQL

60 posts

cloudflare2 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.

Read original(opens in new tab)
google4 min readCurated summary

Designing synthetic datasets for the real world: Mechanism design and reasoning from first principles

Synthetic data generation should be treated as dataset-level mechanism design rather than one-sample-at-a-time prompting. Google’s Simula framework uses reasoning models to control coverage, diversity, complexity, and quality independently, enabling seedless, reproducible datasets for scarce or privacy-sensitive domains. Experiments across five domains show that thoughtfully designed data can outperform larger datasets, but the best configuration depends on the target task and model. ## Why Real-World Data Is Insufficient - Specialized AI applications often lack accessible data because domains are uncommon, expensive to label, or privacy-sensitive. - Manually creating datasets is costly, slow, and error-prone. - Real-world datasets are static, limiting rapid iteration and making it difficult to proactively generate safety edge cases. - Synthetic-first workflows can make data programmable, versioned, reproducible, and inspectable. ## Limitations of Existing Synthetic Data Methods - Many approaches depend on manual prompts, evolutionary algorithms, or large amounts of seed data. - These dependencies reduce scalability and explainability. - Generation parameters are often entangled, making it difficult to independently control diversity, difficulty, and correctness. - Most methods optimize individual samples instead of designing the dataset’s overall distribution. ## Simula’s Reasoning-First Design - Simula constructs datasets from first principles using reasoning models rather than opaque generation processes. - The framework is seedless and agentic, allowing improvements as the underlying models become better at reasoning. - It separates generation into independently controllable axes. ### Global Diversification - Reasoning models map a domain into deep, hierarchical taxonomies that serve as sampling scaffolds. - A recursive propose-and-refine process generates candidate categories, then evaluates, merges, and filters them with a critic model. - These taxonomies help datasets cover long-tail concepts instead of concentrating on common examples. - The approach was demonstrated with structures such as a Cyber Threat Intelligence taxonomy. ### Local Diversification - Taxonomy nodes are converted into “meta-prompts” representing scenarios. - Multiple distinct instantiations are generated for each scenario. - This reduces mode collapse—for example, representing SQL injection through varied contexts rather than repeating nearly identical questions. ### Complexification - A configurable portion of scenarios is made more elaborate or difficult. - Complexity can therefore be adjusted without changing the dataset’s semantic coverage. - The appropriate difficulty level depends on the capabilities of the model that will consume the data. ### Quality Checks - A dual-critic loop independently assesses whether outputs and answers are correct. - Independent verification helps reduce sycophancy and improves label reliability. - This enables quality control without requiring human review of every example. ## Reasoning-Based Evaluation - Conventional metrics such as embedding cosine distance offer only broad signals and limited practical guidance. - Simula introduces: - **Taxonomic Coverage**, which measures how thoroughly the conceptual space is represented. - **Calibrated Complexity Scoring**, which uses LLM-based batch comparisons and chess-style Elo ratings to estimate the difficulty of individual examples. - These metrics aim to evaluate diversity and difficulty in ways that better reflect downstream usefulness. ## Results Across Domains - Simula was evaluated using Gemini 2.5 Flash as a teacher and Gemma 3 4B as a student. - The experiments covered cybersecurity, legal reasoning, grade-school mathematics, and multilingual academic knowledge, with datasets reaching 512,000 examples per domain. - The full combination of global coverage, local diversity, and quality critique consistently outperformed simpler baselines. - High complexity improved math reasoning accuracy by 10% in GSM8k but harmed legal reasoning performance, where the teacher model was weaker. - Simula often achieved stronger downstream results with fewer examples, suggesting that data properties matter as much as volume. - The findings show that there is no universally optimal synthetic-data recipe; effective dataset design must be tailored to the domain and target model. Synthetic data is most effective when treated as an engineered system rather than a source of additional volume. Practitioners should separately tune coverage, variation, difficulty, and verification, then validate those choices against the downstream task.

Read original(opens in new tab)
gitlab3 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.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Secure private networking for everyone: users, nodes, agents, Workers — introducing Cloudflare Mesh

Cloudflare introduces Mesh as a private networking layer designed for humans, services, and autonomous AI agents. It connects devices, servers, cloud VPCs, Workers, Durable Objects, and Agents SDK applications without exposing private services publicly or relying on manual VPN and SSH workflows. Mesh builds on Cloudflare One, so existing Gateway policies, Access rules, device posture checks, and other Zero Trust controls apply automatically. ## Why Agent Workloads Need Private Networking - AI agents increasingly need access to private databases, APIs, repositories, MCP servers, object stores, and home infrastructure. - Traditional solutions are poorly suited to autonomous software: - VPNs often require interactive login. - SSH tunnels require manual setup. - Public exposure increases the risk of unauthorized access. - Basic connectivity does not provide sufficient visibility into agent activity. - Agents may have powerful permissions, including shell, filesystem, and network access, making misconfiguration especially dangerous. ## New Agentic Workflows - **Accessing personal agents remotely** - A user can run an agent such as OpenClaw on a home Mac mini. - Phones, laptops, and work devices can connect securely without exposing the agent directly to the public Internet. - **Letting coding agents access staging systems** - Agents such as Claude Code, Cursor, or Codex can reach private staging databases, analytics systems, APIs, and object stores. - Developers avoid exposing those systems or tunneling an entire laptop into a cloud VPC. - **Connecting deployed agents to private services** - Agents running on Cloudflare Workers can call internal APIs and databases. - Mesh is intended to provide scoped access, auditability, and reduced credential exposure. ## How Cloudflare Mesh Works - Mesh uses a lightweight connector and a single binary to connect: - Personal devices - Remote servers - User endpoints - Private cloud networks - Connected devices communicate over private IPs through Cloudflare’s global network, which spans more than 330 cities. - Cloudflare’s existing terminology is simplified: - WARP Connector becomes a **Cloudflare Mesh node**. - WARP Client becomes the **Cloudflare One Client**. - Example deployments include: - Connecting an iPhone to a home Mac mini running an agent. - Connecting a developer laptop to staging databases and internal APIs. - Connecting Linux servers and external cloud VPCs so agents can reach private resources and MCP servers. ## Security and Cloudflare One Integration - Mesh traffic automatically inherits Cloudflare One protections, including: - Gateway network, DNS, and HTTP policies - Device posture checks - DNS filtering - Access rules - Existing Cloudflare One customers can use Mesh without adopting a separate security platform. - Organizations can later expand into: - Access for Infrastructure for SSH and RDP management - Browser Isolation - Data Loss Prevention - Cloud Access Security Broker capabilities - The goal is to protect agent traffic with the same controls already used for human users and services. Cloudflare Mesh is positioned as a practical starting point for securely connecting agents to private infrastructure. Teams can begin with simple private networking and later add more advanced Zero Trust controls without migrating to a different platform.

Read original(opens in new tab)
aws3 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.

Read original(opens in new tab)
cloudflare3 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.

Read original(opens in new tab)
line3 min readCurated summary

The Key to AI Utilization Lies in 'Organizational Learning' - The Start of the Orchestration Development Workshop

LY Corporation is moving from simply adopting AI tools to building with AI as a collaborative development partner. Its new Orchestration Development Workshop teaches engineers to coordinate multiple AI systems across coding, testing, reviews, incident analysis, and other workflows. The initiative aims not only to improve efficiency but to free engineers from repetitive work so they can focus on more creative, high-value challenges. ## From AI Adoption to AI Collaboration - AI-assisted development and operations are spreading rapidly across LY Corporation. - Engineers use generative AI for code generation and testing, while combining it with non-generative AI for analysis and operational optimization. - Despite broader adoption, employees differ significantly in how deeply they use AI in their daily work. - The workshop was created to help the organization evolve from “using AI” to “creating alongside AI.” ## Orchestration: Coordinating Multiple AI Systems - “Orchestration” refers to combining multiple AIs, along with human input, to produce a complete outcome. - Example workflows include: - Generating code automatically from a Jira ticket. - Having AI run tests, conduct reviews, and create a pull request. - Analyzing a Slack incident report, estimating the cause, and proposing a fix. - The workshop turns these emerging practices into hands-on learning rather than passive demonstrations. ## A Hands-On, Interactive Learning Model - Participants follow instructors in real time and perform the same tasks themselves. - Zoom conversations and Slack questions create two-way communication during the session. - Instructors and representative participants explore solutions to problems as they arise. - The goal is for attendees to gain skills they can reproduce in their own projects, not merely acquire theoretical knowledge. ## Organization-Wide Support Through Guilds and DevRel - The initiative is designed to avoid depending on individual enthusiasm. - Three complementary functions support continuous growth: - **DevRel:** Drives the program and promotes adoption. - **Guilds:** Contribute practical insights from engineering teams. - **TD:** Helps maintain quality and reproducibility. - This structure supports consistent content quality and enables AI knowledge to spread across the company. ## Beyond Efficiency: Unlocking Engineering Creativity - LY Corporation views AI as more than a way to complete tasks faster. - By delegating repetitive work to AI, engineers can spend more time on creative and strategically valuable activities. - The organization aims to move beyond a model where AI writes code and humans only review it. - Instead, engineers should collaborate with AI from the design stage through implementation. ## Future Direction - LY Corporation plans to share lessons from the workshops through external channels such as its technology blog. - Future topics will include both generative and non-generative AI. - The broader goal is to provide practical guidance for engineers building new workflows with AI. The workshop represents a structured way to turn AI experimentation into repeatable organizational practice, helping engineers coordinate multiple AI tools while preserving human creativity and judgment.

Read original(opens in new tab)
aws3 min readCurated summary

AWS Weekly Roundup: AWS AI/ML Scholars program, Agent Plugin for AWS Serverless, and more (March 30, 2026) | Amazon Web Services

The March 30, 2026 AWS Weekly Roundup highlights the new AWS AI & ML Scholars program, which will offer free generative AI education to up to 100,000 people and fully funded Udacity Nanodegrees to 4,500 top participants. It also emphasizes new tools for serverless development, SageMaker IDE integration, expanded Lambda Managed Instance capacity, and streaming speech synthesis. AWS Summit and Community Day events are also scheduled worldwide. ## AWS AI & ML Scholars Program - Open to anyone aged 18 or older, with no prior AI or machine learning experience required. - Includes: - A foundational generative AI Challenge phase. - A fully funded three-month Udacity Nanodegree for the top 4,500 performers. - Applications close June 24, 2026. ## Serverless and Database Improvements - **Aurora PostgreSQL express configuration** enables serverless databases to be created and connected in seconds using preconfigured defaults. - **Aurora PostgreSQL is now part of the AWS Free Tier**, with eligible new customers receiving AWS credits. - The **Agent Plugin for AWS Serverless** adds skills, sub-agents, and Model Context Protocol servers to AI coding assistants such as Kiro, Claude Code, and Cursor. - It supports building, deploying, troubleshooting, and managing production-ready serverless applications. - The **Aurora DSQL Connector for Ruby** automatically generates authentication tokens for each connection while remaining compatible with the `pg` gem. ## SageMaker and AWS Console Updates - **SageMaker Studio** now supports remote connections from Kiro and Cursor, combining those IDEs’ coding workflows with SageMaker’s scalable compute. - The AWS Management Console now supports visual customization, including account colors and hiding unused regions or services to reduce interface clutter. ## Expanded Lambda Managed Instance Capacity - The file descriptor limit has increased from 1,024 to 4,096, supporting higher-concurrency and file-intensive workloads. - Functions can now use up to: - 32 GB of memory - 16 vCPUs - Users can select memory-to-vCPU ratios of 2:1, 4:1, or 8:1 for workloads such as data processing, media transcoding, and scientific simulations. ## Conversational Speech with Amazon Polly - Polly’s new Bidirectional Streaming API supports incremental text-to-speech generation. - Audio synthesis can begin before an LLM or other application has produced the complete response, making it better suited to conversational AI. ## Upcoming AWS Events - AWS Summits are free, in-person events covering cloud, AI, best practices, and networking. - Upcoming locations include Paris, London, Bengaluru, Singapore, Tel Aviv, and Stockholm. - AWS Community Days in San Francisco and Romania will feature community-led talks, workshops, and hands-on labs. AWS developers can follow the AWS News Blog and “What’s New with AWS” for additional announcements, while the AWS Builder Center and Events and Webinars pages provide opportunities for learning and community participation.

Read original(opens in new tab)
aws3 min readCurated summary

Announcing Amazon Aurora PostgreSQL serverless database creation in seconds | Amazon Web Services

Amazon’s new Aurora PostgreSQL express configuration lets developers create a serverless database in seconds with two console clicks or a single CLI/API call. It uses preconfigured defaults, IAM authentication, and an internet access gateway to simplify secure connections without requiring a VPC, VPN, or Direct Connect. The feature is designed to accelerate prototyping and application development while preserving Aurora capabilities such as read replicas and automated failover. ## Express Configuration for Aurora PostgreSQL - Creates an Aurora PostgreSQL serverless cluster and instance within seconds. - Uses preconfigured defaults to reduce setup complexity. - Allows customization of: - Cluster identifier - Serverless capacity range during creation - Read replicas and parameter groups after creation - Express-configured clusters do not require an Amazon VPC. - An internet access gateway is enabled by default for secure connections from development tools worldwide. - The gateway is distributed across multiple Availability Zones for high availability. - IAM authentication is configured for the administrator, enabling passwordless database authentication. ## Creating a Database - In the Aurora and RDS console: - Open the Dashboard. - Choose **Create** with the rocket icon. - Review or adjust the express configuration. - Choose **Create database**. - The AWS CLI and SDKs support the `--with-express-configuration` parameter. - A single `create-db-cluster` call creates both the cluster and its instance: ```bash aws rds create-db-cluster \ --db-cluster-identifier channy-express-db \ --engine aurora-postgresql \ --with-express-configuration ``` - The database becomes ready when its status changes to **Available**. ## Connecting to the Database The **Connectivity & security** tab provides several connection methods: - **Code snippets** - Generates connection examples for .NET, Go, JDBC, Node.js, PHP, PostgreSQL, Python, and TypeScript. - Python examples use `boto3` to generate an IAM authentication token and `psycopg2` to connect over SSL. - **AWS CloudShell** - Launches a shell with a preconfigured `psql` connection command. - Developers can immediately run SQL commands at the PostgreSQL prompt. - **Endpoints** - Supports tools such as pgAdmin that use username-and-password fields. - The password is an IAM authentication token valid for 15 minutes. - A new token must be generated if the connection ends or the token expires. ## Application Development Integrations - Aurora is now included among eligible AWS Free Tier database services. - AWS’s enhanced Free Tier offers up to $200 in credits: - $100 upon signup - Up to another $100 through usage of services such as RDS, Lambda, and Bedrock - Integrations with Vercel and v0 allow developers to create or connect to AWS databases quickly. - v0 can use natural-language prompts to generate full-stack applications backed by Aurora PostgreSQL, Aurora DSQL, or DynamoDB. - Existing Aurora databases created with express configuration can also be connected to Vercel. The express configuration is best suited for quickly starting development, experimentation, and prototypes. Developers can begin with minimal networking and authentication setup, then add capacity, replicas, and other Aurora features as their application grows.

Read original(opens in new tab)
datadog1 min readCurated summary

When upserts don't update but still write: Debugging Postgres performance at scale

The provided content does not include the tech blog post itself. It consists primarily of Datadog’s website navigation and a promotional link about its Gartner recognition, so there is not enough article content to summarize reliably. ## Available Information - Datadog was named a Leader in the 2026 Gartner® Magic Quadrant™ for Observability Platforms. - The page navigation lists Datadog products across: - Infrastructure and application monitoring - Database and log management - Security - Digital experience monitoring - Software delivery - Incident and service management - AI-powered observability tools - The URL path references `debugging-postgres-performance`, suggesting the intended article may concern PostgreSQL performance debugging, but the article text is not included. Please provide the blog post’s body or a working text extraction for a substantive summary.

Read original(opens in new tab)
datadog3 min readCurated summary

When upserts don't update but still write: Debugging Postgres performance at scale

Datadog needed to track when ephemeral hosts were last seen so inactive hosts could be deleted after seven days. A seemingly inexpensive PostgreSQL upsert caused disk writes to double and WAL syncs to quadruple, despite most operations not changing any data. Investigating the WAL revealed that conflict-handling upserts still lock conflicting rows and generate WAL activity, consuming the database’s limited write capacity. ## Tracking Host Activity Efficiently - Hosts stop reporting telemetry when they terminate, but Datadog has no direct termination signal. - Hosts inactive for seven days can be safely removed from the metadata store. - Updating the main host table on every observation would be too expensive because: - Large data centers generate more than 25,000 observations per second. - PostgreSQL MVCC creates a new row version for every update. - Updating the main table would rewrite all host metadata. - Datadog created a separate `host_last_ingested` table containing: - `host_id` as the primary key - `last_ingested` with a default timestamp - The table used `fillfactor=80` to leave page space for future updates. - No index was created on `last_ingested`, allowing updates to use Heap-Only Tuples (HOT) and avoid additional index writes. - Because only daily freshness was required, the timestamp needed to change at most once per day. ## The Conditional Upsert The initial query inserted a host if it did not exist and otherwise updated `last_ingested` only when the previous value was more than a day old: ```sql INSERT INTO host_last_ingested AS t VALUES ($1, now()) ON CONFLICT (host_id) DO UPDATE SET last_ingested = EXCLUDED.last_ingested WHERE t.last_ingested < EXCLUDED.last_ingested - '1 day'::interval; ``` - New hosts produced an insert. - Recently seen hosts matched the conflict but were expected to be no-ops because of the `WHERE` clause. - The team therefore expected most queries to avoid meaningful writes. ## Unexpected Disk and WAL Activity - During a gradual rollout at roughly 500 upserts per second: - Insertions initially increased as expected. - Actual updates remained mostly flat. - Write IOPS more than doubled. - WAL syncs increased by approximately the same amount. - This showed that the absence of an applied update did not mean the query was free. - Since PostgreSQL must flush WAL records at transaction commit, additional WAL activity directly increased disk pressure. - A PostgreSQL cluster’s single-writer design makes this write budget particularly important. ## Inspecting PostgreSQL WAL - PostgreSQL records database changes in its Write-Ahead Log, including table changes, index modifications, and related transaction activity. - The team used the `pg_walinspect` extension, available starting in PostgreSQL 15: ```sql CREATE EXTENSION pg_walinspect; ``` - Its `pg_get_wal_records_info` function allows inspection of WAL records between two Log Sequence Numbers (LSNs). - Examining the WAL helped explain why the conditional upsert generated writes even when the `WHERE` condition prevented the row update. - The underlying issue was that `ON CONFLICT DO UPDATE` still locks the conflicting row, and that locking activity is recorded in the WAL. The key lesson is that a PostgreSQL upsert that reports zero processed rows is not necessarily a true no-op. Conditional conflict updates can still create substantial WAL and locking overhead, so WAL inspection is essential when database write metrics do not match apparent update volume.

Read original(opens in new tab)
line4 min readCurated summary

Internalizing without specifications: Proving equivalence through validation logic

The article describes how LINE Plus safely internalized black-box e-commerce systems without specifications or source code. The team built an automated equivalence-testing loop using Kafka, CDC, OpenSearch, and ksqlDB to compare legacy and new behavior at massive scale. By repeatedly identifying differences, fixing logic, and rechecking results, they could reduce discrepancies toward zero while also measuring performance and protecting production stability. ## Domain: Products, Catalogs, and Data Ingestion - **Products** are individual seller-listed items, potentially with different prices and shipping conditions. - **Catalogs** group products representing the same model or product type and provide derived value such as: - Real-time lowest prices - Unit-price metrics such as price per 100 ml - **Ingestion** receives large product files from sellers, validates and transforms them into internal formats, and updates product and catalog data. - Because the platform contains tens of millions of catalogs and hundreds of millions of products, small logic differences can affect the entire service. ## The Verification Loop - The goal was not merely to find errors, but to help developers understand and correct them quickly. - Inputs had to be identical for both systems, such as: - The same IDs - The same time-based snapshot - The same product files - Outputs were compared according to system type: - API response objects - Database update values - Final registered product data - The general loop consisted of: - **Trigger:** Database changes, developer requests, or file arrivals - **Execution:** Send identical inputs to legacy and new systems - **Comparison:** Apply logic suited to reads, updates, or end-to-end flows - **Processing:** Store detailed differences and produce real-time statistics - **Action:** Developers inspect dashboards or Slack alerts, fix the implementation, and repeat ## Query Logic Verification - The catalog API was difficult to reproduce because it had over 100 response fields, complex filters, undocumented defaults, and unknown sorting behavior. - CDC streamed database binary-log changes into Kafka, allowing verification to begin from many real catalog states. - The verifier made dual API calls and compared legacy and new responses field by field. - Responses were converted into `Map<String, Object>` structures and compared recursively, avoiding the need to model every response class. - If values differed only because list ordering varied, the verifier sorted serialized values and performed a second comparison. - This helped distinguish real implementation defects from harmless ordering differences. - Kafka isolated verification traffic from production services while handling large event volumes. - Difference events were written to Kafka topics and indexed in OpenSearch for detailed investigation. - ksqlDB aggregated streaming discrepancies and sent Slack notifications when abnormal patterns appeared. - Rate limiting restricted repeated errors, such as those from the same field, to a manageable sample per minute. - Because both APIs were called in parallel, the same pipeline also measured and compared their response times. ## Update Logic Verification - The second case involved recalculating catalog statistics whenever product or catalog data changed. - Unlike read verification, this process tested state transitions and asynchronous updates. - When CDC detected a relevant change: - The new statistics logic calculated an expected result. - The verifier compared it with the result actually written by the legacy logic. - Recursive Map-based comparison checked deeply nested statistics fields. - To avoid wasting resources, verification was triggered only for updates related to the catalog-statistics module. ## Handling Asynchronous Lag - Kafka-based processing caused timing gaps: the verifier could read the database before the legacy update had completed. - The team introduced an **N-attempt retry queue**: - Temporarily inconsistent events were requeued. - Only differences that remained after several retries were treated as genuine defects. - The verifier remained a separate process rather than being embedded in the production statistics stream. - This avoided adding load or latency to the existing processing pipeline while preserving independent verification. ## ETL Batch Verification for Missing Triggers - Real-time comparison could detect incorrect results, but not cases where an update should have happened and never occurred. - During refactoring, a complex combination of product and catalog field changes contained a missing trigger condition. - As a result, some statistics remained stale without generating any comparison event. - To detect these silent omissions, the team designed a separate batch-verification process using ETL data alongside the real-time stream checks. The practical recommendation is to treat system internalization as an evidence-building process: define identical inputs and observable outputs, compare legacy and replacement systems continuously, isolate verification through event streams, and supplement real-time checks with batch validation for silent or missing updates.

Read original(opens in new tab)
kakao4 min readCurated summary

From Student to Developer: Learning Rational Choices Over Right Answers—From DB and Security to AI

The onboarding of 40 new Kakao developers shifted their perspective from making features work to designing systems that survive real-world operations. Across databases, security, and AI, they learned that there is rarely one perfect answer; the best choice depends on scale, risk, maintainability, and business needs. The central lesson was to replace theoretical correctness with responsible, adaptable engineering judgment. ## Database: From Finding the Right Answer to Preparing for Change - Database design must be evaluated by whether it can withstand traffic, schema changes, and operational demands—not only by theoretical correctness. - Foreign keys are not automatically the best choice: - They can introduce locking, performance, and flexibility concerns. - Referential integrity can instead be managed at the application layer, provided testing and correction processes are strong. - Soft deletion, using fields such as `deleted_at`, supports auditability and recovery and is often an essential operational strategy. - Indexes should be selected according to the questions the database must answer: - B-tree, GIN, GiST, SP-GiST, and vector indexes serve different data and query patterns. - Execution plans reveal whether SQL uses indexes or performs full table scans, directly affecting I/O and response times. - Duplication is not always harmful: - Intentional denormalization can avoid expensive joins. - Snapshot data can simplify reads and preserve the information needed by a business workflow. - In MongoDB, embedding selected related data can make screen queries much simpler than relying exclusively on references. - Different database systems embody different trade-offs among performance, consistency, scalability, and operational cost. - The training covered MySQL high availability, PostgreSQL primary-key structures, cloud-native systems such as Neon, and the broader storage-to-analysis pipeline of Hadoop and Spark. - The resulting mindset favors designs that are safe to change and affordable to operate over designs that are theoretically perfect. ## Security and IT: From Someone Else’s Responsibility to a Personal Default - Security became a direct consequence of developers’ code rather than merely a compliance or infrastructure concern. - Everyday safeguards such as development/production separation, VPNs, and antivirus software demonstrate that safety often requires accepting some inconvenience. - DDoS defense is not only about blocking traffic: - It can be difficult to distinguish an attack from legitimate traffic spikes caused by a popular event. - Developers should apply basic controls such as rate limiting and escalate suspicious activity through established response channels. - Hands-on API exploitation made vulnerabilities concrete and encouraged developers to view security through an attacker’s perspective. - Security must be continuous: - AI is increasingly being used both to discover vulnerabilities and to strengthen attacks. - Social-engineering methods involving QR codes, app permissions, and human behavior require more than purely technical defenses. - Security checks should be integrated from the beginning of development, not performed only at the end. - Software quality also depends on people: - Code should remain understandable enough for another developer to take over quickly. - Strong engineering means choosing and communicating the most appropriate solution for the business context, not merely finding a technically possible one. ## AI: From Chatting with Models to Designing Systems - An AI agent is not simply a model; it is an architecture composed of tools, routing logic, error handling, and model calls. - Agent development applies familiar software-engineering practices to probabilistic models. - Because LLM outputs can vary, reliable systems need deliberate controls: - Prompt chaining breaks large tasks into smaller steps and limits context contamination. - Few-shot examples clarify required output formats. - Routing selects different prompts or workflows based on conditions. - Multi-agent systems divide responsibilities among specialized agents, echoing the modularity and scalability principles of microservices. - RAG reduces hallucinations structurally by: - Chunking documents. - Searching for semantically similar vectors. - Supplying retrieved information to the model as additional context. - MCP exposes internal systems and data as callable tools, effectively enabling remote function calling and connecting AI to enterprise capabilities. - Effective AI use shifted from criticizing poor answers to specifying clear objectives, formats, examples, context, and supporting data. - The goal is not merely to receive an intelligent response, but to design a system that consistently produces intelligent behavior. The training ultimately marked a transition from student-style problem solving to professional engineering. Developers should consider operational resilience, security, maintainability, and business value, then make and clearly explain the most reasonable choice for the circumstances.

Read original(opens in new tab)
kakao4 min readCurated summary

From Student to Developer: Learning Server Flow from Lotto Implementation to Legacy Improvement

The post describes Kakao’s 2026 server-engineering onboarding program, which turns uncertainty into practical understanding through structured implementation, testing, and refactoring. Rather than supplying fixed answers, the program repeatedly asks developers to explain their design decisions and assess what their tests protect. Its central lesson is that server development becomes manageable when engineers build clear reasoning, maintainable structures, and safe change processes. ## Onboarding Through Three Stages - The program follows a progression: 1. TDD- and OOP-based implementation 2. Acceptance testing for legacy code 3. Refactoring legacy code - The focus is not only on what to build, but on how to make engineering decisions. - Core goals include: - Designing maintainable structures - Analyzing and safely improving legacy systems - Collaborating effectively, including responsible AI usage - Although originally designed for server developers, the program expanded to frontend, Android, and iOS engineers because engineering principles apply across technology stacks. ## Learning Through Questions and Collaboration - Participants were repeatedly asked: - Why was this design chosen? - Does this object truly own this responsibility? - What behavior does this test protect? - Daily meetings, pair programming, troubleshooting discussions, and PR reviews made development a collaborative activity. - The program aimed to develop engineers who could explain and defend their designs, rather than merely produce working code. ## Mission 1: Building a Lottery Game with TDD and OOP - The first assignment implemented: - Automatic and manual lottery purchases - A fixed ticket price of 1,000 won - Winning-statistics calculations - Constraints encouraged better design: - One level of indentation - Methods limited to 10 lines - Primitive values wrapped in value objects - First-class collections - Avoiding `else` through early returns - TDD required tests to be written before implementation. ### Making Randomness Testable - Random lottery-number generation initially made tests unpredictable and tightly coupled to concrete implementations. - The solution was to: - Introduce a number-generation interface - Inject the generation strategy - Create a separate test generator - This made test results controllable and encouraged a more flexible design. ### Considering Value Objects and Caching - The team also questioned whether identical number values should always create new objects. - This led to discussions about caching and the difference between object identity and value equality. - The main lesson was to evaluate design decisions, not just make the feature work. ## Mission 2: Writing Acceptance Tests for Legacy Code - Participants first protected the existing system before modifying it. - Tests focused on externally observable behavior: - User actions - System responses - State changes - Strong assertions verified not merely that an operation succeeded, but that it produced the correct result. - Cucumber-based BDD expressed scenarios in a form understandable to non-developers, treating tests as shared specifications. ### Achieving Production Parity - To avoid “works on my machine” problems, the test environment was aligned with production: - PostgreSQL replaced H2 - Docker standardized execution environments - Gradle tasks automated test execution - Test-data isolation used: - Reverse-order foreign-key deletion - `TRUNCATE ... CASCADE` - Shared cleanup utilities - These measures ensured tests started from consistent, independent states. ## Mission 3: Refactoring Legacy Code Safely - The final mission treated refactoring as training in decision-making, not simply an exercise in clean code. - The central rule was to separate structural and behavioral changes: - Structural changes must preserve behavior. - Behavior changes must avoid unrelated structural modifications. - PR reviews helped identify unintended behavior changes and taught participants to predict and control the effects of modifications. - AI was used during refactoring to accelerate broad code changes, but large changes were difficult to verify, highlighting the need to control scope and validate changes carefully. The onboarding’s practical recommendation is to approach server development through small, explainable decisions: write controllable tests, protect legacy behavior before changing it, separate refactoring from feature changes, and use AI as an assistant rather than a substitute for engineering judgment.

Read original(opens in new tab)
aws3 min readCurated summary

AWS Weekly Roundup: Amazon Connect Health, Bedrock AgentCore Policy, GameDay Europe, and more (March 9, 2026) | Amazon Web Services

The March 9, 2026 AWS Weekly Roundup highlights AWS’s growing focus on agentic AI, healthcare automation, security, and developer productivity. Major updates include Amazon Connect Health, centralized policies for Bedrock agents, private AI assistants on Lightsail, and new tools for troubleshooting and durable Lambda workflows. The roundup also previews community events, including GameDay Europe, NVIDIA GTC, AWS Summits, and regional Community Days. ## Major AWS Product Launches - **Amazon Connect Health** is generally available with five healthcare-focused AI agents: - Patient verification - Appointment management - Patient insights - Ambient documentation - Medical coding - These capabilities are HIPAA-eligible and designed to integrate with existing clinical workflows within days. - **Bedrock AgentCore Policy** provides centralized, fine-grained controls for agent-to-tool interactions. - Policies can be written in natural language. - AWS converts them into Cedar, its open-source policy language. - Controls operate outside application code, supporting security and compliance teams. - **OpenClaw on Amazon Lightsail** enables deployment of private autonomous AI assistants. - Includes sandboxed sessions, security controls, HTTPS, and device-pairing authentication. - Uses Amazon Bedrock by default and supports Slack, Telegram, WhatsApp, and Discord integrations. ## Pricing, Cost Management, and Security - **VPC Encryption Controls** became a paid feature on March 1, 2026. - Monitor mode detects unencrypted traffic. - Enforce mode blocks traffic that does not meet encryption requirements. - Controls apply to traffic within and across VPCs in a region. - **Database Savings Plans** now cover Amazon OpenSearch Service and Amazon Neptune Analytics. - Customers can save up to 35% with a one-year commitment. - Savings apply across engine, instance family, size, and AWS Region. - **Amazon GameLift Servers DDoS Protection** adds a co-located relay network. - Client traffic is authenticated with access tokens. - Per-player traffic limits help mitigate attacks. - The feature adds no cost for GameLift Servers customers. ## Developer and Operations Improvements - **Elastic Beanstalk AI-powered environment analysis** sends events, health data, and logs to Amazon Bedrock when environments degrade. - It returns troubleshooting recommendations tailored to the affected environment. - AWS now allows **IAM roles to be created directly inside service workflows**, reducing the need to switch to the IAM console. Supported services include EC2, Lambda, EKS, ECS, Glue, and CloudFormation. - **Kiro’s new Lambda durable functions power** assists developers with long-running, multi-step applications and AI workflows. - It provides guidance on replay models, waits, concurrency, error handling, and deployment. ## AWS Community Projects - One community project demonstrates a persistent AI memory layer using **MCP, Amazon Bedrock, and a Chrome extension**, allowing agents to retain context across sessions and applications. - Another experimental application treats the AI model as the runtime, generating a complete interactive web application from a single prompt without a conventional codebase, framework, or persistent state. ## Community Events and AWS Activities - **AWS Community GameDay Europe** takes place March 17, offering team-based challenges using real AWS services. - AWS will participate in **NVIDIA GTC 2026** in San Jose from March 16–19, with sessions, demos, booths, and discounted passes. - Upcoming **AWS Summits** include Paris, London, and Bengaluru. - Upcoming **AWS Community Days** include events in Slovakia, Pune, and Mexico City. AWS’s latest announcements show a clear emphasis on practical AI agents, stronger governance, and automation across infrastructure and application development. Developers and cloud teams should review the new security and pricing changes while exploring the AI tools and upcoming hands-on community events.

Read original(opens in new tab)