Home / Companies / PlanetScale / Blog / October 2026

October 2026 Summaries

4 posts from PlanetScale

Filter
Month: Year:
Post Summaries Back to Blog
No summary generated yet.
Oct 08, 2026 1,884 words in the original blog post.
Admission control determines whether software work should proceed based on factors such as permissions, capacity, priority, or concurrency, and the text traces one common mechanism, the leaky bucket, from ancient water clocks and Athenian court time limits to modern network and API rate limiting. In software, leaky or token buckets track the amount of admitted work and replenish capacity over time, allowing bursts while enforcing a sustainable average rate; Shopify’s GraphQL API is presented as an example that prices requests by estimated query cost and exposes bucket state to clients. The piece argues that databases particularly need pre-execution admission controls because systems such as Postgres and MySQL can attempt more work than they can safely handle, while existing timeout settings often act only after resources have been consumed. It introduces PlanetScale’s Database Traffic Control for Postgres as a system that uses tagged queries and resource budgets to warn on or block work before execution, estimating query costs from plans and historical behavior and applying settings for server share, burst capacity, per-query limits, and concurrent workers.
Oct 07, 2026 1,835 words in the original blog post.
PlanetScale has introduced dedicated read replicas for Postgres, allowing users to create, size, configure, and connect to asynchronously replicated database instances independently of the primary cluster. Replicas can be deployed in geographically distant regions to reduce read latency for global users or within the same region to isolate workloads such as vector search, analytics, and long-running queries from transactional production traffic. They can be managed through the PlanetScale dashboard, API, or CLI, with configurable compute, memory, disk size, IOPS, throughput, and storage characteristics tailored to each replica’s needs.
Oct 06, 2026 365 words in the original blog post.
Neki, a PostgreSQL sharding router, is designed to minimize overhead by retaining PostgreSQL protocol bytes and decoding data only when routing, sorting, grouping, or other operations require it. Unlike systems that eagerly convert every returned row and column into internal objects, Neki can forward raw query responses directly to clients, inspect only bind parameters needed to select a shard, and preserve text or binary value formats. For cross-shard queries, it progressively exposes more structure as needed: limits require identifying row boundaries, global sorting requires decoding only sort keys, and projections can remove or reorder columns by copying raw column frames rather than deserializing values. Fully decoding and reserializing values remains necessary for operations such as cross-shard aggregation, where the router must compare group keys and generate new results. This layered model allows rows to combine original wire messages with selectively cached decoded values, improving efficiency while preserving correctness for complex data types, encodings, NULLs, extension values, and byte-sensitive cases such as floating-point NaN payloads.
Oct 01, 2026 3,546 words in the original blog post.