# Blog -- PlanetScale

Posts about the PlanetScale platform, MySQL, PostgreSQL, databases, and more.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Introducing TIN: full-text search for Postgres

DevFeed: [Introducing TIN: full-text search for Postgres](<https://devfeed.tech/articles/introducing-tin-full-text-search-for-postgres-31551.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/introducing-tin>)

Author: Patrick Reynolds

Published: 2026-09-16T00:00:00Z

Content type: release

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [benchmarking](<https://devfeed.tech/topics/benchmarking.md>)

Tags: [backups](<https://devfeed.tech/tags/backups.md>), [benchmark](<https://devfeed.tech/tags/benchmark.md>), [benchmarks](<https://devfeed.tech/tags/benchmarks.md>), [bm25](<https://devfeed.tech/tags/bm25.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [full-text-search](<https://devfeed.tech/tags/full-text-search.md>), [index](<https://devfeed.tech/tags/index.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [reddit](<https://devfeed.tech/tags/reddit.md>), [replication](<https://devfeed.tech/tags/replication.md>), [search](<https://devfeed.tech/tags/search.md>), [text](<https://devfeed.tech/tags/text.md>), [wikipedia](<https://devfeed.tech/tags/wikipedia.md>)

### AI overview

PlanetScale announces TIN, a full-text search extension for Postgres and Neki databases. The article describes supported query and matching features, transaction and update behavior, and benchmark workloads and corpora used to assess performance.

### Source excerpt

TIN is a fast, full-featured, full-text search index for Postgres

## 118 million queries per second on Neki

DevFeed: [118 million queries per second on Neki](<https://devfeed.tech/articles/118-million-queries-per-second-on-neki-2320.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/118-million-queries-per-second-on-neki>)

Author: Hirad Pourtahmasbi

Published: 2026-09-11T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [Latency](<https://devfeed.tech/topics/latency.md>)

Tags: [benchmark](<https://devfeed.tech/tags/benchmark.md>), [database](<https://devfeed.tech/tags/database.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [errors](<https://devfeed.tech/tags/errors.md>), [latency](<https://devfeed.tech/tags/latency.md>), [neki](<https://devfeed.tech/tags/neki.md>), [postgres](<https://devfeed.tech/tags/postgres.md>)

### AI overview

The article reports a Neki benchmark that sustained 118 million queries per second across 512 primary-only Postgres shards holding 1.22 PiB of data. The read-only, single-shard point-select workload ran for 16 minutes, with reported router and client p99 latency plus fleet IOPS, network throughput, and error rate.

### Source excerpt

We ran a massive, sharded Postgres database at 118.5 million queries per second, with 200k queries per second on each shard across 512 shards.

## Introducing Neki

DevFeed: [Introducing Neki](<https://devfeed.tech/articles/introducing-neki-2326.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/introducing-neki>)

Author: Nick Van Wiggeren

Published: 2026-09-10T12:00:00Z

Content type: release

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>)

Tags: [database](<https://devfeed.tech/tags/database.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [neki](<https://devfeed.tech/tags/neki.md>), [platform](<https://devfeed.tech/tags/platform.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [product](<https://devfeed.tech/tags/product.md>), [routing](<https://devfeed.tech/tags/routing.md>), [scale](<https://devfeed.tech/tags/scale.md>), [workflow](<https://devfeed.tech/tags/workflow.md>)

### AI overview

PlanetScale announces Neki in platform preview, a sharded Postgres offering designed to scale a database across multiple machines while retaining Postgres compatibility.

### Source excerpt

Neki, sharded Postgres by PlanetScale, is now available in platform preview.

## The lifecycle of a sharded Postgres query

DevFeed: [The lifecycle of a sharded Postgres query](<https://devfeed.tech/articles/the-lifecycle-of-a-sharded-postgres-query-2338.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/the-lifecycle-of-a-sharded-postgres-query>)

Author: PlanetScale

Published: 2026-09-10T00:00:00Z

Content type: tutorial

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [networking](<https://devfeed.tech/topics/networking.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [auth](<https://devfeed.tech/tags/auth.md>), [database](<https://devfeed.tech/tags/database.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [neki](<https://devfeed.tech/tags/neki.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [routing](<https://devfeed.tech/tags/routing.md>), [scale](<https://devfeed.tech/tags/scale.md>), [server](<https://devfeed.tech/tags/server.md>), [sql](<https://devfeed.tech/tags/sql.md>)

### AI overview

An overview of how a SQL query moves through a sharded Postgres database, from authentication and routing to execution across shards.

### Source excerpt

Follow a SQL query through the router, across four Postgres shards, and back.

## What is a Neki router?

DevFeed: [What is a Neki router?](<https://devfeed.tech/articles/what-is-a-neki-router-2342.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/what-is-a-neki-router>)

Author: Ahmed Darwich

Published: 2026-09-01T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [Processes](<https://devfeed.tech/topics/processes.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [database](<https://devfeed.tech/tags/database.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [neki](<https://devfeed.tech/tags/neki.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [processes](<https://devfeed.tech/tags/processes.md>), [scale](<https://devfeed.tech/tags/scale.md>), [sql](<https://devfeed.tech/tags/sql.md>)

### AI overview

Neki routers sit between applications and Postgres, routing and coordinating queries across sharded database instances while handling client connections independently of Postgres backend processes.

### Source excerpt

A Neki router gives applications a Postgres connection to one database while planning and coordinating queries across the shards behind it.

## How one connection kills a database

DevFeed: [How one connection kills a database](<https://devfeed.tech/articles/how-one-connection-kills-a-database-2325.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/debugging-live-database-connections>)

Author: Simeon Griggs

Published: 2026-08-31T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [debugging](<https://devfeed.tech/topics/debugging.md>), [migration](<https://devfeed.tech/topics/migration.md>), [dashboards](<https://devfeed.tech/topics/dashboards.md>), [vitess](<https://devfeed.tech/topics/vitess.md>)

Tags: [app](<https://devfeed.tech/tags/app.md>), [cli](<https://devfeed.tech/tags/cli.md>), [database](<https://devfeed.tech/tags/database.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [errors](<https://devfeed.tech/tags/errors.md>), [exception](<https://devfeed.tech/tags/exception.md>), [github](<https://devfeed.tech/tags/github.md>), [management](<https://devfeed.tech/tags/management.md>), [migration](<https://devfeed.tech/tags/migration.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [product](<https://devfeed.tech/tags/product.md>), [transactions](<https://devfeed.tech/tags/transactions.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

The article explains how an unclosed database transaction can block a migration and queue later queries, causing downtime. It discusses diagnosing live MySQL and Postgres connections and preventing stuck Postgres transactions with a timeout.

### Source excerpt

Unblock stuck connections with live connection management in the PlanetScale CLI and dashboard

## Problems with large tables in Postgres

DevFeed: [Problems with large tables in Postgres](<https://devfeed.tech/articles/problems-with-large-tables-in-postgres-2324.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/dealing-with-large-tables-in-postgres>)

Author: Simeon Griggs

Published: 2026-08-25T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [Database](<https://devfeed.tech/topics/database.md>), [neki](<https://devfeed.tech/topics/neki.md>), [vitess](<https://devfeed.tech/topics/vitess.md>)

Tags: [cpu](<https://devfeed.tech/tags/cpu.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [neki](<https://devfeed.tech/tags/neki.md>), [network](<https://devfeed.tech/tags/network.md>), [outage](<https://devfeed.tech/tags/outage.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

The article explains how large, wide, or oversized Postgres tables can create performance and reliability problems. It describes a cascade-delete incident that caused timeouts, excessive WAL generation, replica lag, primary overload, and an outage. It presents partitioning, vertical scaling, and sharding as possible approaches, emphasizing sharding with Neki as a solution for large Postgres tables.

### Source excerpt

Postgres presents pretty predictable performance problems when dealing with large tables. Sharding solves this.

## The history of Postgres sharding

DevFeed: [The history of Postgres sharding](<https://devfeed.tech/articles/the-history-of-postgres-sharding-2337.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/the-history-of-postgres-sharding>)

Author: Josh Brown

Published: 2026-08-24T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [Database](<https://devfeed.tech/topics/database.md>), [vitess](<https://devfeed.tech/topics/vitess.md>), [Tooling](<https://devfeed.tech/topics/tooling.md>), [LAMP](<https://devfeed.tech/topics/lamp.md>)

Tags: [complexity](<https://devfeed.tech/tags/complexity.md>), [database](<https://devfeed.tech/tags/database.md>), [databases](<https://devfeed.tech/tags/databases.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [history](<https://devfeed.tech/tags/history.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [neki](<https://devfeed.tech/tags/neki.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [scale](<https://devfeed.tech/tags/scale.md>), [servers](<https://devfeed.tech/tags/servers.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

The article traces the history of database sharding, focusing on why Postgres took longer than MySQL to develop mature sharding solutions. It discusses the origins of the term "shard," the role of MySQL's ecosystem and tools such as Vitess, and how companies including Facebook and YouTube addressed growth and increasing database workloads.

### Source excerpt

Why has it taken so long to get good Postgres sharding? The last 20 years are the answer.

## Poisoned Postgres connection pools

DevFeed: [Poisoned Postgres connection pools](<https://devfeed.tech/articles/poisoned-postgres-connection-pools-2331.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/postgres-poisoned-connection-pools>)

Author: Josh Brown

Published: 2026-08-18T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [postgresql clusters](<https://devfeed.tech/topics/postgresql-clusters.md>), [client](<https://devfeed.tech/topics/client.md>), [API](<https://devfeed.tech/topics/api.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [database](<https://devfeed.tech/tags/database.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [postgres](<https://devfeed.tech/tags/postgres.md>)

### AI overview

The article explains how stale session state can poison Postgres connection pools, causing reused connections to remain read-only and trigger errors. It focuses on connection pooling, PgBouncer transaction mode, and the resulting effects on client queries and API routes.

### Source excerpt

An engineer's worst nightmare is waking up to a seemingly read-only database with no clear issue in sight. Let's dig into why this happens, and how AI can help solve it.

## What is a data topology?

DevFeed: [What is a data topology?](<https://devfeed.tech/articles/what-is-a-data-topology-2341.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/what-is-a-data-topology>)

Author: Ahmed Darwich

Published: 2026-08-17T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [data](<https://devfeed.tech/topics/data.md>), [vitess](<https://devfeed.tech/topics/vitess.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [data](<https://devfeed.tech/tags/data.md>), [database](<https://devfeed.tech/tags/database.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [internals](<https://devfeed.tech/tags/internals.md>), [json](<https://devfeed.tech/tags/json.md>), [mapping](<https://devfeed.tech/tags/mapping.md>), [neki](<https://devfeed.tech/tags/neki.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [routing](<https://devfeed.tech/tags/routing.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [transactions](<https://devfeed.tech/tags/transactions.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

The article explains Neki data topologies: JSON configurations that map logical PostgreSQL tables to physical shard groups so routers can place data and route queries.

### Source excerpt

A data topology describes the sharding scheme a Neki router uses to map logical PostgreSQL tables to physical shards and route queries.

## The dangers of Postgres subtransactions

DevFeed: [The dangers of Postgres subtransactions](<https://devfeed.tech/articles/the-dangers-of-postgres-subtransactions-2335.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/the-dangers-of-postgres-subtransactions>)

Author: Etienne Berube

Published: 2026-08-11T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [postgresql clusters](<https://devfeed.tech/topics/postgresql-clusters.md>), [Database](<https://devfeed.tech/topics/database.md>), [Server](<https://devfeed.tech/topics/server.md>), [data](<https://devfeed.tech/topics/data.md>)

Tags: [availability](<https://devfeed.tech/tags/availability.md>), [data](<https://devfeed.tech/tags/data.md>), [database](<https://devfeed.tech/tags/database.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [server](<https://devfeed.tech/tags/server.md>)

### AI overview

Postgres subtransactions can reduce throughput across an entire PostgreSQL cluster and prevent newly added read replicas from accepting queries. The article explains how replicas replay the primary's WAL and determine when they can safely serve reads.

### Source excerpt

Subtransactions can slow down your entire PostgreSQL server and break your high availability strategy by keeping new read replicas from accepting connections.

## Concurrency vs. Throughput: why more parallelism can make databases slower

DevFeed: [Concurrency vs. Throughput: why more parallelism can make databases slower](<https://devfeed.tech/articles/concurrency-vs-throughput-why-more-parallelism-can-make-databases-slower-2321.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/concurrency-vs-throughput-vitess-mysql>)

Author: Liz van Dijk

Published: 2026-08-07T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>), [vitess](<https://devfeed.tech/topics/vitess.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [bug](<https://devfeed.tech/topics/bug.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>)

Tags: [bug](<https://devfeed.tech/tags/bug.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [databases](<https://devfeed.tech/tags/databases.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

Increasing database parallelism can reduce throughput and destabilize a production system. The article examines how a long-running MySQL transaction, growing version history, retries, and an uncapped request surge caused widespread failures, and explains how Vitess transaction timeouts and connection-pool limits can contain the impact.

### Source excerpt

Increasing throughput sometimes requires reducing parallelism. A look into why this is the case for Vitess + MySQL databases

## Massively parallel Postgres backups

DevFeed: [Massively parallel Postgres backups](<https://devfeed.tech/articles/massively-parallel-postgres-backups-2328.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/massively-parallel-postgres-backups>)

Author: Ben Dicken

Published: 2026-07-31T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [neki](<https://devfeed.tech/topics/neki.md>), [cloud-infrastructure](<https://devfeed.tech/topics/cloud-infrastructure.md>), [Amazon S3](<https://devfeed.tech/topics/amazon-s3.md>), [Orchestration](<https://devfeed.tech/topics/orchestration.md>), [Server](<https://devfeed.tech/topics/server.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>), [Terraform](<https://devfeed.tech/topics/terraform.md>)

Tags: [amazon-s3](<https://devfeed.tech/tags/amazon-s3.md>), [backup](<https://devfeed.tech/tags/backup.md>), [building](<https://devfeed.tech/tags/building.md>), [databases](<https://devfeed.tech/tags/databases.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [infrastructure](<https://devfeed.tech/tags/infrastructure.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [neki](<https://devfeed.tech/tags/neki.md>), [orchestration](<https://devfeed.tech/tags/orchestration.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [scale](<https://devfeed.tech/tags/scale.md>), [servers](<https://devfeed.tech/tags/servers.md>), [storage](<https://devfeed.tech/tags/storage.md>)

### AI overview

PlanetScale describes how Neki, its sharded Postgres system, performs consistent encrypted backups at petabyte scale. The approach combines filesystem backups, archived WAL replay, object storage such as Amazon S3, and massive parallelism to back up databases without affecting production queries.

### Source excerpt

PlanetScale backs up petabyte-scale sharded Postgres databases in hours using parallel infrastructure, object storage, and WAL replay.

## Postgres backups under the hood

DevFeed: [Postgres backups under the hood](<https://devfeed.tech/articles/postgres-backups-under-the-hood-2330.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/postgres-backups-under-the-hood>)

Author: Josh Brown

Published: 2026-07-24T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [data](<https://devfeed.tech/topics/data.md>), [SQL](<https://devfeed.tech/topics/sql.md>), [IO](<https://devfeed.tech/topics/io.md>), [Filesystems](<https://devfeed.tech/topics/filesystems.md>)

Tags: [backup](<https://devfeed.tech/tags/backup.md>), [data](<https://devfeed.tech/tags/data.md>), [database](<https://devfeed.tech/tags/database.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [io](<https://devfeed.tech/tags/io.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [recovery](<https://devfeed.tech/tags/recovery.md>), [sql](<https://devfeed.tech/tags/sql.md>)

### AI overview

This article explains how Postgres backups work, focusing on logical backups and their tradeoffs. It describes consistent snapshots, SQL or custom output formats, resource costs at large data volumes, the lack of point-in-time recovery, and the use of MVCC for online backups.

### Source excerpt

With backups being such a vital part of keeping your data safe, how do they actually work?

## What's new in Postgres 19

DevFeed: [What's new in Postgres 19](<https://devfeed.tech/articles/what-s-new-in-postgres-19-2343.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/whats-new-in-postgres-19>)

Author: Ahmed Darwich

Published: 2026-07-23T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Code](<https://devfeed.tech/topics/code.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>)

### AI overview

An overview of PostgreSQL 19's planned improvements, focusing on an in-core online table-rewrite capability that can reclaim bloated-table space while allowing reads and writes to continue. The article also discusses existing rewrite approaches, table bloat, dead tuples, and related extensions.

### Source excerpt

`VACUUM` reclaims dead-tuple space but doesn't shrink a table. PostgreSQL 19 Beta 2 adds an in-core online rewrite with REPACK (CONCURRENTLY), and much more.

## Every UPDATE Leaves a Ghost: MVCC, Bloat, and VACUUM in PostgreSQL

DevFeed: [Every UPDATE Leaves a Ghost: MVCC, Bloat, and VACUUM in PostgreSQL](<https://devfeed.tech/articles/every-update-leaves-a-ghost-mvcc-bloat-and-vacuum-in-postgresql-2332.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/postgresql-mvcc>)

Author: Ahmed Darwich

Published: 2026-07-20T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>)

Tags: [concurrency](<https://devfeed.tech/tags/concurrency.md>), [database](<https://devfeed.tech/tags/database.md>), [deep-dive](<https://devfeed.tech/tags/deep-dive.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [transactions](<https://devfeed.tech/tags/transactions.md>), [update](<https://devfeed.tech/tags/update.md>), [updates](<https://devfeed.tech/tags/updates.md>)

### AI overview

An in-depth PostgreSQL article on MVCC: how concurrent transactions use row versions and snapshot visibility, why updates leave dead tuples, and how this can cause table bloat before VACUUM reclaims space.

### Source excerpt

What happens to old row versions after nobody needs them? They become dead tuples, and over time they bloat your tables. Go deeper into PostgreSQL MVCC with runnable psql examples.

## Making 768 servers look like 1

DevFeed: [Making 768 servers look like 1](<https://devfeed.tech/articles/making-768-servers-look-like-1-2327.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/making-768-servers-look-like-1>)

Author: Ben Dicken

Published: 2026-07-15T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [backends](<https://devfeed.tech/topics/backends.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [database](<https://devfeed.tech/tags/database.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [servers](<https://devfeed.tech/tags/servers.md>)

### AI overview

An article about scaling Postgres databases through sharding, from a single node to hundreds of servers. It describes resource bottlenecks, read replicas, and the role of application architecture at high query volume.

### Source excerpt

How to make 768 distinct Postgres servers look like 1 to your applications.

## When the Postgres query planner goes rogue

DevFeed: [When the Postgres query planner goes rogue](<https://devfeed.tech/articles/when-the-postgres-query-planner-goes-rogue-2344.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/when-the-postgres-query-planner-goes-rogue>)

Author: Nick Van Wiggeren

Published: 2026-07-13T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [cpu](<https://devfeed.tech/topics/cpu.md>)

Tags: [cpu](<https://devfeed.tech/tags/cpu.md>), [database](<https://devfeed.tech/tags/database.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [insights](<https://devfeed.tech/tags/insights.md>), [latency](<https://devfeed.tech/tags/latency.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [resource](<https://devfeed.tech/tags/resource.md>), [sql](<https://devfeed.tech/tags/sql.md>), [statistics](<https://devfeed.tech/tags/statistics.md>)

### AI overview

PlanetScale describes containing a runaway Postgres query whose planner choice caused severe latency and CPU saturation. A strict Database Traffic Control budget stopped further executions while the customer investigated the root cause.

### Source excerpt

How PlanetScale Database Traffic Control contained a runaway Postgres query after the planner abandoned an index.

## Deadlocks and downtime

DevFeed: [Deadlocks and downtime](<https://devfeed.tech/articles/deadlocks-and-downtime-2323.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/deadlocks-and-downtime>)

Author: Simeon Griggs

Published: 2026-07-08T00:00:00Z

Content type: tutorial

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [Deadlock](<https://devfeed.tech/topics/deadlock.md>), [Transactions](<https://devfeed.tech/topics/transactions.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Concurrent Programming](<https://devfeed.tech/topics/concurrent-programming.md>)

Tags: [database](<https://devfeed.tech/tags/database.md>), [deadlock](<https://devfeed.tech/tags/deadlock.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [errors](<https://devfeed.tech/tags/errors.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [learn](<https://devfeed.tech/tags/learn.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [reduce](<https://devfeed.tech/tags/reduce.md>), [transactions](<https://devfeed.tech/tags/transactions.md>)

### AI overview

This article explains how Postgres deadlocks arise when concurrent transactions hold locks that each other needs, and how those deadlocks can escalate into database downtime. It examines the effects of high query volume and immediate retry loops, then recommends consistent row-update ordering, smaller transactions, and late locking to reduce the risk.

### Source excerpt

Deadlocks happen when transactions block each other. Learn how they escalate into downtime, how to reduce them through better queries and retry logic, and how Traffic Control can protect your database from your application.

## One Postgres cluster, many apps

DevFeed: [One Postgres cluster, many apps](<https://devfeed.tech/articles/one-postgres-cluster-many-apps-2329.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/one-postgres-cluster-many-apps>)

Author: Simeon Griggs

Published: 2026-06-25T00:00:00Z

Content type: tutorial

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [postgresql clusters](<https://devfeed.tech/topics/postgresql-clusters.md>), [Database](<https://devfeed.tech/topics/database.md>), [App](<https://devfeed.tech/topics/app.md>), [Authorization](<https://devfeed.tech/topics/authorization.md>)

Tags: [administration](<https://devfeed.tech/tags/administration.md>), [apps](<https://devfeed.tech/tags/apps.md>), [complexity](<https://devfeed.tech/tags/complexity.md>), [database](<https://devfeed.tech/tags/database.md>), [databases](<https://devfeed.tech/tags/databases.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [side-projects](<https://devfeed.tech/tags/side-projects.md>)

### AI overview

This tutorial explains how multiple small applications can share a single PlanetScale Postgres cluster through separate logical databases. It covers clusters, branches, logical databases, roles, permissions, and the tradeoff between shared infrastructure for side projects and dedicated clusters for applications that need to scale.

### Source excerpt

Yo, I heard you liked databases, so we put logical databases in your database cluster so you can database while you database

## The feedback loops behind Kubernetes

DevFeed: [The feedback loops behind Kubernetes](<https://devfeed.tech/articles/the-feedback-loops-behind-kubernetes-2336.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/the-feedback-loops-behind-kubernetes>)

Author: Fatih Arslan

Published: 2026-06-16T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Database](<https://devfeed.tech/topics/database.md>)

Tags: [containers](<https://devfeed.tech/tags/containers.md>), [database](<https://devfeed.tech/tags/database.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [linux](<https://devfeed.tech/tags/linux.md>), [loops](<https://devfeed.tech/tags/loops.md>), [storage](<https://devfeed.tech/tags/storage.md>)

### AI overview

An explanation of Kubernetes operators as feedback controllers that reconcile desired and observed state, illustrated through running a production database in containers.

### Source excerpt

Kubernetes is a framework for feedback controllers: write down what you want, observe what exists, make the next change, and repeat.

## See what your database is doing right now with Connections

DevFeed: [See what your database is doing right now with Connections](<https://devfeed.tech/articles/see-what-your-database-is-doing-right-now-with-connections-2334.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/see-what-your-database-is-doing-right-now>)

Author: Brett Warminski

Published: 2026-06-15T00:00:00Z

Content type: release

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [debugging](<https://devfeed.tech/topics/debugging.md>), [vitess](<https://devfeed.tech/topics/vitess.md>), [Command-line interface](<https://devfeed.tech/topics/cli.md>), [Processes](<https://devfeed.tech/topics/processes.md>)

Tags: [cli](<https://devfeed.tech/tags/cli.md>), [database](<https://devfeed.tech/tags/database.md>), [databases](<https://devfeed.tech/tags/databases.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [incident](<https://devfeed.tech/tags/incident.md>), [logs](<https://devfeed.tech/tags/logs.md>), [monitor](<https://devfeed.tech/tags/monitor.md>), [process](<https://devfeed.tech/tags/process.md>), [product](<https://devfeed.tech/tags/product.md>), [resources](<https://devfeed.tech/tags/resources.md>), [tools](<https://devfeed.tech/tags/tools.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

Connections is a new PlanetScale CLI feature for Postgres and Vitess databases. It provides a live, refreshable view of active sessions, highlights blocked queries and waiting states, shows blocker trees, maintains recent history, and lets developers capture the observed session data for later handoff.

### Source excerpt

Connections lets you monitor and manage all active connections to Postgres and Vitess databases. See active sessions, identify locking patterns, and keep debugging even when normal application connections are exhausted.

## The only scalable delete in Postgres is DROP TABLE

DevFeed: [The only scalable delete in Postgres is DROP TABLE](<https://devfeed.tech/articles/the-only-scalable-delete-in-postgres-is-drop-table-2339.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/the-only-scalable-delete>)

Author: Tom Pang

Published: 2026-06-11T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [Transactions](<https://devfeed.tech/topics/transactions.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>)

Tags: [database](<https://devfeed.tech/tags/database.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [replication](<https://devfeed.tech/tags/replication.md>)

### AI overview

The article explains why large row-level DELETE operations do not scale well in Postgres: they add write and replication overhead, may delay other writers, and generally do not return physical disk space to the operating system. It recommends database designs that make large-scale deletion possible through DROP TABLE or TRUNCATE.

### Source excerpt

Large DELETEs add work instead of reclaiming it. Structure your database so deletion becomes DROP TABLE or TRUNCATE.

## Egress problems and where to find them

DevFeed: [Egress problems and where to find them](<https://devfeed.tech/articles/egress-problems-and-where-to-find-them-2322.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/database-egress>)

Author: Simeon Griggs

Published: 2026-05-14T00:00:00Z

Content type: article

Language: en

Sources: [Blog -- PlanetScale](<https://devfeed.tech/sources/blog-planetscale.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [Database](<https://devfeed.tech/topics/database.md>), [data](<https://devfeed.tech/topics/data.md>), [App](<https://devfeed.tech/topics/app.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>)

Tags: [applications](<https://devfeed.tech/tags/applications.md>), [availability](<https://devfeed.tech/tags/availability.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [data](<https://devfeed.tech/tags/data.md>), [database](<https://devfeed.tech/tags/database.md>), [databases](<https://devfeed.tech/tags/databases.md>), [efficiency](<https://devfeed.tech/tags/efficiency.md>), [high-availability](<https://devfeed.tech/tags/high-availability.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [product](<https://devfeed.tech/tags/product.md>), [reduce](<https://devfeed.tech/tags/reduce.md>), [scale](<https://devfeed.tech/tags/scale.md>)

### AI overview

The article explains how reducing database egress by fetching less data and making requests less frequently can improve application performance while lowering costs. It focuses on Postgres examples, including query limits, selecting specific columns, and extracting needed values from JSONB data.

### Source excerpt

Reducing the size and frequency of requests to your database has the double benefit of making your applications faster and cheaper.

[Next page](<https://devfeed.tech/sources/blog-planetscale.md?cursor=WyIyMDI2LTA1LTE0VDAwOjAwOjAwKzAwOjAwIiwgImFmODY2MTFhLTlhOTctNGY3NC1hZDhiLTM5YTIwMmFmYzU5NCJd>)