March 2026 Summaries

Graceful degradation in Postgres, as discussed by Ben Dicken, involves prioritizing database queries to maintain essential functionality during traffic surges, such as those caused by viral events or DDoS attacks. Using PlanetScale's Traffic Control, resource budgets are implemented to categorize and prioritize different types of queries, ensuring high-priority operations like user authentication and post fetching are not disrupted by less critical tasks, such as impression counts and notifications. The process involves tagging SQL queries with metadata using sqlcommenter, which allows for the allocation of server resources based on priority levels—critical, important, and best-effort. This system not only prevents total database outages but also allows for dynamic adjustments to resource allocation in real-time, ensuring that core functionalities remain operational during unexpected load spikes. Over time, the budgets can be fine-tuned by starting in a warning mode to monitor and adjust limits without affecting users, ultimately enabling a smooth transition to enforcement mode to maintain optimal performance under varying conditions.

High memory usage in Postgres, particularly in the context of caching, is often indicative of a healthy and efficient system rather than a problem. Unlike high CPU usage, which can lead to bottlenecks and increased latency, high memory usage primarily reflects the database's ability to keep frequently accessed data in RAM, thus reducing the need for slower disk reads. Postgres utilizes two primary layers of caching: its own buffer pool, shared_buffers, and the operating system's page cache, both of which aim to minimize expensive disk operations. However, memory usage can become problematic when Resident Set Size (RSS) increases due to inefficient memory allocation, poorly configured extensions, or excessive concurrent connections, potentially leading to out-of-memory events and degraded performance. Understanding the difference between cache-related memory usage and process memory can help diagnose performance issues, and tools like Query Insights can assist in identifying patterns that contribute to high RSS. Ultimately, monitoring and managing the types of memory usage is crucial to maintaining a performant Postgres database.

Stripe Projects is a new developer preview initiative from Stripe that aims to streamline the process of discovering, provisioning, and paying for developer tools through a single centralized workflow within the Stripe CLI. This innovation addresses the historically fragmented nature of developer workflows, which has been exacerbated by the rise of AI agents, by providing a standardized method for reliable provisioning and credential management across providers. As a co-design and launch partner, PlanetScale is participating in this initiative, enabling developers to quickly set up and manage MySQL or Postgres databases from their terminal. Currently in developer preview, Stripe Projects allows users to install the necessary tools via the Stripe CLI, configure Stripe Projects within their applications, and seamlessly create databases with PlanetScale, all without leaving the terminal environment. Users can access the Stripe Marketplace or Stripe Projects documentation for further information and are encouraged to provide feedback through Discord or social media platforms.

Rafer Hazen's blog post discusses the enhancements made to the query tagging feature in Postgres Query Insights, introduced with the Traffic Control launch, which now allows tags to be present in aggregated query data. This advancement facilitates viewing tag distribution, searching queries by tag, and analyzing database statistics per tag. Tags, which are key-value pairs embedded in SQL comments, can be automatically applied at the application level, with Insights adding tags like application_name, username, and remote_address. The new feature provides multiple surfaces for viewing tags, including query patterns, database tags, and query filters. Implementation involves the Insights Postgres extension, Kafka, and ClickHouse, and the new capability addresses previous limitations by associating all query data with relevant tags. Although this increases the number of messages emitted due to unique tag combinations, strategies like cardinality reduction are employed to manage data volume. Cardinality reduction uses per-tag and per-interval limits to collapse high-cardinality tags, ensuring efficient data handling and message emission. The post concludes by highlighting the power of query tagging in providing comprehensive insight into database performance.

Database Traffic Control™ is a newly released feature designed to mitigate and prevent database overload from unexpectedly expensive SQL queries by utilizing the capabilities of Postgres extensions and a sophisticated query management system. The feature leverages hooks in the Postgres architecture to evaluate and manage SQL query execution in real-time, integrating with the existing pginsights extension to measure query resource consumption. By employing mechanisms like static analysis and cumulative resource usage, Traffic Control can block or warn queries based on a set of configurable rules and budgets. It uses a unique leaky-bucket model to manage cumulative query costs, ensuring that high-demand periods do not overwhelm server resources. Traffic Control dynamically estimates query costs by adjusting Postgres's planner cost predictions with real-world execution data, allowing for more precise control over query initiation. This system provides developers and database administrators with enhanced tools to prioritize and regulate SQL traffic efficiently, ensuring stable database operations even under heavy loads.

Database Traffic Control, introduced by PlanetScale for Postgres databases, addresses the challenge of managing unexpected spikes in query traffic that can degrade performance or crash servers. This system allows users to set flexible budgets that determine how much of the database's resources a given workload can consume, with Postgres enforcing these limits. Users can create budgets based on query patterns, application names, database users, and custom tags, enabling resource limits on CPU usage, concurrency, and query timing. Budgets can operate in either warn mode for observation or enforce mode to actively block queries that exceed set limits. This feature proves useful in various scenarios, such as incident response, priority-based traffic shaping, isolating AI from human traffic, and prioritizing different customer tiers in multi-tenant applications. Available through the PlanetScale dashboard, API, and CLI, Database Traffic Control allows for automated budget creation within deployment pipelines, offering a powerful tool for maintaining database stability and performance.

PgBouncer is a lightweight connection pooler that enhances PostgreSQL performance by addressing the limitations of its process-per-connection architecture, which can hinder scalability when numerous clients connect simultaneously. By sitting between the application and the PostgreSQL server, PgBouncer allows thousands of client connections to be multiplexed onto a limited number of server connections, significantly reducing resource consumption and improving efficiency. It primarily operates in transaction pooling mode, which assigns a server connection for the duration of a transaction and returns it to the pool afterward, making it suitable for most applications except those requiring specific features incompatible with this mode. Configuring PgBouncer effectively involves adjusting settings such as max_client_conn, default_pool_size, max_db_connections, and max_user_connections, tailored to individual use cases to ensure optimal performance and connection safety. PlanetScale, among others, advocates for the use of PgBouncer for application traffic, providing options like local, dedicated primary, and dedicated replica PgBouncers, which facilitate different levels of high availability and traffic management.

Drizzle, known for its popular ORM optimized for JavaScript and TypeScript, is joining PlanetScale to enhance their shared commitment to performance and developer experience in database tools. Despite this collaboration, Drizzle will continue as an independent open-source project with its own objectives and roadmap. PlanetScale's support will enable the Drizzle team to concentrate on their core priorities while maintaining the integrity and values of open source. The partnership acknowledges Drizzle's significant impact on the community and expresses excitement for future collaborations as part of the PlanetScale team.