# vitess

Published articles for vitess.

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

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

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

## 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

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

## Supabase Series F

DevFeed: [Supabase Series F](<https://devfeed.tech/articles/supabase-series-f-669.md>)

Original publisher: [Read original article](<https://supabase.com/blog/supabase-series-f>)

Author: Paul Copplestone

Published: 2026-06-04T07:00:00Z

Content type: news

Language: en

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

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

Tags: [announcement](<https://devfeed.tech/tags/announcement.md>), [claude-code](<https://devfeed.tech/tags/claude-code.md>), [codex](<https://devfeed.tech/tags/codex.md>), [database](<https://devfeed.tech/tags/database.md>), [infrastructure](<https://devfeed.tech/tags/infrastructure.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [release](<https://devfeed.tech/tags/release.md>), [series](<https://devfeed.tech/tags/series.md>), [tooling](<https://devfeed.tech/tags/tooling.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

Supabase announces a $500M Series F and releases Multigres v0.1 alpha, an open-source, self-hostable Postgres operating system focused on high availability and operational simplicity.

### Source excerpt

Supabase has raised a $500M Series F at a $10B pre-money valuation, led by GIC.

## Multigres v0.1 Alpha: an operating system for Postgres

DevFeed: [Multigres v0.1 Alpha: an operating system for Postgres](<https://devfeed.tech/articles/multigres-v0-1-alpha-an-operating-system-for-postgres-459.md>)

Original publisher: [Read original article](<https://supabase.com/blog/multigres-v0-1-alpha>)

Author: Sugu Sougoumarane

Published: 2026-06-04T07:00:00Z

Content type: release

Language: en

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

Topics: [Open Source](<https://devfeed.tech/topics/open-source.md>), [Availability](<https://devfeed.tech/topics/availability.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [Orchestration](<https://devfeed.tech/topics/orchestration.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [Deployment](<https://devfeed.tech/topics/deployment.md>), [systems](<https://devfeed.tech/topics/systems.md>), [vitess](<https://devfeed.tech/topics/vitess.md>)

Tags: [availability](<https://devfeed.tech/tags/availability.md>), [aws](<https://devfeed.tech/tags/aws.md>), [backup](<https://devfeed.tech/tags/backup.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [database](<https://devfeed.tech/tags/database.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [high-availability](<https://devfeed.tech/tags/high-availability.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [orchestration](<https://devfeed.tech/tags/orchestration.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [release](<https://devfeed.tech/tags/release.md>), [replication](<https://devfeed.tech/tags/replication.md>), [s3](<https://devfeed.tech/tags/s3.md>), [scale](<https://devfeed.tech/tags/scale.md>), [storage](<https://devfeed.tech/tags/storage.md>), [systems](<https://devfeed.tech/tags/systems.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

Multigres v0.1 alpha is an open-source system for scaling and operating Postgres. It provides connection pooling, automatic failover, backup orchestration, sharding, and horizontal scaling, with Kubernetes deployment support and high-availability features based on Postgres replication and generalized consensus.

### Source excerpt

Today we're releasing Multigres v0.1 alpha to the open source community, bringing Vitess-grade horizontal scaling, high availability, and operational simplicity to Postgres.

## Problem solving with PlanetScale Insights

DevFeed: [Problem solving with PlanetScale Insights](<https://devfeed.tech/articles/problem-solving-with-planetscale-insights-2333.md>)

Original publisher: [Read original article](<https://planetscale.com/blog/problem-solving-with-insights>)

Author: Simeon Griggs

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

Content type: tutorial

Language: en

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

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

Tags: [database](<https://devfeed.tech/tags/database.md>), [insights](<https://devfeed.tech/tags/insights.md>), [latency](<https://devfeed.tech/tags/latency.md>), [mcp](<https://devfeed.tech/tags/mcp.md>), [mcp-server](<https://devfeed.tech/tags/mcp-server.md>), [metrics](<https://devfeed.tech/tags/metrics.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [product](<https://devfeed.tech/tags/product.md>), [production](<https://devfeed.tech/tags/production.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

A walkthrough of using PlanetScale Insights to identify database query-performance problems in production, with emphasis on latency percentiles and dashboard metrics for PlanetScale Postgres.

### Source excerpt

The best way for you and your agents to see how your database actually performs in production.

## Announcing Multigres: Vitess for Postgres

DevFeed: [Announcing Multigres: Vitess for Postgres](<https://devfeed.tech/articles/announcing-multigres-vitess-for-postgres-460.md>)

Original publisher: [Read original article](<https://supabase.com/blog/multigres-vitess-for-postgres>)

Author: Paul Copplestone

Published: 2025-06-10T07:00:00Z

Content type: release

Language: en

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

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

Tags: [availability](<https://devfeed.tech/tags/availability.md>), [database](<https://devfeed.tech/tags/database.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

Supabase announces Multigres, a Postgres-focused proxy inspired by Vitess. The project aims to provide a gradual path from connection pooling and high availability to sharding for large-scale Postgres workloads.

### Source excerpt

Today we are welcoming Sugu, the co-creator of Vitess, to the Supabase team. He is joining Supabase to build Multigres: Vitess for Postgres.

## Why HTAP Databases Are Giving Way to Disaggregated Architectures

DevFeed: [Why HTAP Databases Are Giving Way to Disaggregated Architectures](<https://devfeed.tech/articles/htap-is-dead-5421.md>)

Original publisher: [Read original article](<https://neon.com/blog/htap-is-dead>)

Author: Zhou Sun

Published: 2025-05-04T10:00:00Z

Content type: article

Language: en

Sources: [Blog -- Neon Docs](<https://devfeed.tech/sources/blog-neon-docs.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [olap](<https://devfeed.tech/topics/olap.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [consistency](<https://devfeed.tech/topics/consistency.md>), [NoSQL](<https://devfeed.tech/topics/nosql.md>), [MongoDB](<https://devfeed.tech/topics/mongodb.md>), [Hadoop](<https://devfeed.tech/topics/hadoop.md>), [hdfs](<https://devfeed.tech/topics/hdfs.md>), [CockroachDB](<https://devfeed.tech/topics/cockroachdb.md>), [Amazon Redshift](<https://devfeed.tech/topics/amazon-redshift.md>), [vitess](<https://devfeed.tech/topics/vitess.md>)

Tags: [cloud](<https://devfeed.tech/tags/cloud.md>), [cloud-data](<https://devfeed.tech/tags/cloud-data.md>), [cockroachdb](<https://devfeed.tech/tags/cockroachdb.md>), [consistency](<https://devfeed.tech/tags/consistency.md>), [data-lake](<https://devfeed.tech/tags/data-lake.md>), [databases](<https://devfeed.tech/tags/databases.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [hadoop](<https://devfeed.tech/tags/hadoop.md>), [hdfs](<https://devfeed.tech/tags/hdfs.md>), [latency](<https://devfeed.tech/tags/latency.md>), [mongodb](<https://devfeed.tech/tags/mongodb.md>), [olap](<https://devfeed.tech/tags/olap.md>), [redshift](<https://devfeed.tech/tags/redshift.md>), [sql](<https://devfeed.tech/tags/sql.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

The article traces the separation of transactional and analytical database workloads, explaining how differing storage and scaling requirements led to specialized OLTP and OLAP systems. It argues that HTAP as a single database architecture is declining while its underlying ideas persist in today's disaggregated data stack.

### Source excerpt

This blog is inspired by Jordan Tigani's "Big Data is Dead." Jordan and I actually spent some time building an HTAP database at SingleStore. From the one database that did everything in the '80s, to the great divide, to HTAP, to today's disaggregated stack--here's why HTAP as a database is dead, but its spirit lives on.

## Cash App on PlanetScale Metal

DevFeed: [Cash App on PlanetScale Metal](<https://devfeed.tech/articles/cash-app-on-planetscale-metal-29014.md>)

Original publisher: [Read original article](<https://code.cash.app/planetscale-metal>)

Author: Aaron Young

Published: 2025-03-11T00:00:00Z

Content type: article

Language: en

Sources: [Cash App Code Blog](<https://devfeed.tech/sources/cash-app-code-blog.md>)

Topics: [migration](<https://devfeed.tech/topics/migration.md>), [vitess](<https://devfeed.tech/topics/vitess.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Availability](<https://devfeed.tech/topics/availability.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>)

Tags: [availability](<https://devfeed.tech/tags/availability.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [migration](<https://devfeed.tech/tags/migration.md>), [mount](<https://devfeed.tech/tags/mount.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [storage](<https://devfeed.tech/tags/storage.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

Cash App describes its migration from self-managed Vitess and MySQL infrastructure in its datacenters to PlanetScale's cloud-managed product, and its subsequent work with PlanetScale to migrate its fleet to PlanetScale Metal. The article explains the original architecture and reports storage-volume degradation, manual shard failovers, and periods when shards could not accept writes.

### Source excerpt

Cash App moves to PlanetScale to drive efficiencies

## Horizontally scaling the Rails backend of Shop app with Vitess

DevFeed: [Horizontally scaling the Rails backend of Shop app with Vitess](<https://devfeed.tech/articles/horizontally-scaling-the-rails-backend-of-shop-app-with-vitess-1410.md>)

Original publisher: [Read original article](<https://shopify.engineering/horizontally-scaling-the-rails-backend-of-shop-app-with-vitess>)

Author: Hammad Khalid

Published: 2024-01-17T20:34:53Z

Content type: article

Language: en

Sources: [Shopify Engineering](<https://devfeed.tech/sources/shopify-engineering.md>), [Shopify Engineering - Shopify Engineering](<https://devfeed.tech/sources/shopify-engineering-shopify-engineering.md>)

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

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [backend](<https://devfeed.tech/tags/backend.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

The article describes scaling the Shop app's Ruby on Rails backend as growth pushed its MySQL datastore toward its limits, culminating in an approach centered on Vitess.

### Source excerpt

Shop app horizontally scaled a Ruby on Rails app with Vitess. This blog describes Vitess and our detailed approach for introducing Vitess to a Rails app.

## Shard Splits with Consistent Snapshots

DevFeed: [Shard Splits with Consistent Snapshots](<https://devfeed.tech/articles/shard-splits-with-consistent-snapshots-15848.md>)

Original publisher: [Read original article](<https://developer.squareup.com/blog/shard-splits-with-consistent-snapshots>)

Author: Andrés Taylor

Published: 2018-12-04T17:00:00Z

Content type: tutorial

Language: en

Sources: [Square Corner Blog RSS Feed](<https://devfeed.tech/sources/square-corner-blog-rss-feed.md>)

Topics: [vitess](<https://devfeed.tech/topics/vitess.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [data](<https://devfeed.tech/topics/data.md>), [Algorithm](<https://devfeed.tech/topics/algorithm.md>)

Tags: [algorithm](<https://devfeed.tech/tags/algorithm.md>), [customers](<https://devfeed.tech/tags/customers.md>), [database](<https://devfeed.tech/tags/database.md>), [databases](<https://devfeed.tech/tags/databases.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [locks](<https://devfeed.tech/tags/locks.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [vitess](<https://devfeed.tech/tags/vitess.md>)

### AI overview

This tutorial explains how Square performs gradual MySQL shard splits using Vitess while data continues changing. It covers online cloning, inconsistent destination copies, and consistent snapshots to reduce application impact during the process.

### Source excerpt

How to take a copy of something too large to fit in a single shot