+
+For additional details on each of the components, see [Concepts](../../concepts).
diff --git a/content/en/docs/21.0/overview/cloud-native.md b/content/en/docs/21.0/overview/cloud-native.md
new file mode 100644
index 000000000..7baea63e1
--- /dev/null
+++ b/content/en/docs/21.0/overview/cloud-native.md
@@ -0,0 +1,19 @@
+---
+title: Cloud Native
+weight: 4
+---
+
+Vitess is well-suited for Cloud deployments because it enables databases to incrementally add capacity. The easiest way to run Vitess in the Cloud is via Kubernetes.
+
+## Vitess on Kubernetes
+
+Kubernetes is an open-source orchestration system for containerized applications, and Vitess can run as a Kubernetes-aware cloud native distributed database.
+
+Kubernetes handles scheduling onto nodes in a compute cluster, actively manages workloads on those nodes, and groups containers comprising an application for easy management and discovery. This provides an analogous open-source environment to the way Vitess ran in YouTube on Borg, the predecessor to Kubernetes.
+
+An open-source Kubernetes [operator](https://github.com/planetscale/vitess-operator) is available for Vitess, and is being used in production by several deployments.
+
+**Related Vitess Documentation**
+
+* [Kubernetes Quickstart](../../get-started/operator/)
+
diff --git a/content/en/docs/21.0/overview/history.md b/content/en/docs/21.0/overview/history.md
new file mode 100644
index 000000000..b91d4b3e5
--- /dev/null
+++ b/content/en/docs/21.0/overview/history.md
@@ -0,0 +1,19 @@
+---
+title: History
+description: Born at YouTube, released as Open Source
+weight: 5
+---
+
+Vitess was created in 2010 to solve the MySQL scalability challenges that the team at YouTube faced. This section briefly summarizes the sequence of events that led to Vitess' creation:
+
+1. YouTube's MySQL database reached a point when peak traffic would soon exceed the database's serving capacity. To temporarily alleviate the problem, YouTube created a master database for write traffic and a replica database for read traffic.
+2. With demand for cat videos at an all-time high, read-only traffic was still high enough to overload the replica database. So YouTube added more replicas, again providing a temporary solution.
+3. Eventually, write traffic became too high for the master database to handle, requiring YouTube to shard data to handle incoming traffic. As an aside, sharding would have also become necessary if the overall size of the database became too large for a single MySQL instance.
+4. YouTube's application layer was modified so that before executing any database operation, the code could identify the right database shard to receive that particular query.
+
+Vitess let YouTube remove that logic from the application source code, introducing a proxy between the application and the database to route and manage database interactions. Since then, YouTube has scaled its user base by a factor of more than 50, greatly increasing its capacity to serve pages, process newly uploaded videos, and more. Even more importantly, Vitess is a platform that continues to scale.
+
+## Vitess becomes a CNCF project
+
+The [CNCF](https://www.cncf.io) serves as the vendor-neutral home for many of the fastest-growing open source projects. In [February 2018](https://www.cncf.io/blog/2018/02/05/cncf-host-vitess/) the Technical Oversight Committee (TOC) voted to accept Vitess as a CNCF incubation project. Vitess became the eighth CNCF project to graduate in [November 2019](https://www.cncf.io/announcement/2019/11/05/cloud-native-computing-foundation-announces-vitess-graduation/), joining Kubernetes, Prometheus, Envoy, CoreDNS, containerd, Fluentd, and Jaeger.
+
diff --git a/content/en/docs/21.0/overview/img/architecture.svg b/content/en/docs/21.0/overview/img/architecture.svg
new file mode 100644
index 000000000..f5fecc21c
--- /dev/null
+++ b/content/en/docs/21.0/overview/img/architecture.svg
@@ -0,0 +1,86 @@
+
diff --git a/content/en/docs/21.0/overview/scalability-philosophy.md b/content/en/docs/21.0/overview/scalability-philosophy.md
new file mode 100644
index 000000000..ee261ac79
--- /dev/null
+++ b/content/en/docs/21.0/overview/scalability-philosophy.md
@@ -0,0 +1,75 @@
+---
+title: Scalability Philosophy
+weight: 3
+aliases: ['/docs/launching/scalability-philosophy/']
+---
+
+Scalability problems can be solved using many approaches. This document describes Vitess' approach to address these problems.
+
+## Small instances
+
+When deciding to shard or break databases up into smaller parts, it's tempting to break them just enough that they fit in one machine. In the industry, it’s common to run only one MySQL instance per host.
+
+Vitess recommends that instances be broken up into manageable chunks (250GB per MySQL server), and not to shy away from running multiple instances per host. The net resource usage would be about the same. But the manageability greatly improves when MySQL instances are small. There is the complication of keeping track of ports, and separating the paths for the MySQL instances. However, everything else becomes simpler once this hurdle is crossed.
+
+There are fewer lock contentions to worry about, replication is a lot happier, production impact of outages is smaller, backups and restores run faster, and a lot more secondary advantages can be realized. For example, you can shuffle instances around to get better machine or rack diversity leading to even smaller production impact on outages, and improved resource usage.
+
+## Durability through replication
+
+Traditional data storage software treated data as durable as soon as it was flushed to disk. However, this approach is impractical in today’s world of commodity hardware. Such an approach also does not address disaster scenarios.
+
+The new approach to durability is achieved by copying the data to multiple machines, and even geographical locations. This form of durability addresses the modern concerns of device failures and disasters.
+
+Many of the workflows in Vitess have been built with this approach in mind. For example, turning on semi-sync replication is highly recommended. This allows Vitess to failover to a new replica when a primary goes down, with no data loss. Vitess also recommends that you avoid recovering a crashed database. Instead, create a fresh one from a recent backup and let it catch up.
+
+Relying on replication also allows you to loosen some of the disk-based durability settings. For example, you can turn off `sync_binlog`, which greatly reduces the number of IOPS to the disk thereby increasing effective throughput.
+
+## Consistency model
+
+Before sharding or moving tables to different keyspaces, the application needs to be verified (or changed) such that it can tolerate the following changes:
+
+* Cross-shard reads may not be consistent with each other. Conversely, the sharding decision should also attempt to minimize such occurrences because cross-shard reads are more expensive.
+* In "best-effort mode", cross-shard transactions can fail in the middle and result in partial commits. You could instead use "2PC mode" transactions that give you distributed atomic guarantees. However, choosing this option increases the write cost by approximately 50%.
+
+Single shard transactions continue to remain ACID, just like MySQL supports it.
+
+If there are read-only code paths that can tolerate slightly stale data, the queries should be sent to REPLICA tablets for OLTP, and RDONLY tablets for OLAP workloads. This allows you to scale your read traffic more easily, and gives you the ability to distribute them geographically.
+
+This trade-off allows for better throughput at the expense of stale or possibly inconsistent reads, since the reads may be lagging behind the primary, as data changes (and possibly with varying lag on different shards). To mitigate this, VTGate servers are capable of monitoring replica lag and can be configured to avoid serving data from instances that are lagging beyond X seconds.
+
+For a true snapshot, queries must be sent to the primary within a transaction. For read-after-write consistency, reading from the primary without a transaction is sufficient.
+
+To summarize, these are the various levels of consistency supported:
+
+* `REPLICA/RDONLY` read: Servers can be scaled geographically. Local reads are fast, but can be stale depending on replica lag.
+* `PRIMARY` read: There is only one worldwide primary per shard. Reads coming from remote locations will be subject to network latency and reliability, but the data will be up-to-date (read-after-write consistency). The isolation level is `READ_COMMITTED`.
+* `PRIMARY` transactions: These exhibit the same properties as PRIMARY reads. However, you get REPEATABLE_READ consistency and ACID writes for a single shard. Support is planned for cross-shard Atomic transactions.
+
+As for atomicity, the following levels are supported:
+
+* `SINGLE`: disallow multi-db transactions.
+* `MULTI`: multi-db transactions with best effort commit.
+* `TWOPC`: multi-db transactions with 2PC commit.
+
+### No active-active replication
+
+Vitess doesn’t support active-active replication setup (previously called multi-master). It has alternate ways of addressing most of the use cases that are typically solved by such a configuration.
+
+* Scalability: There are situations where active-active gives you a little bit of additional runway. However, since all writes have to eventually be applied to all writable servers, it’s not a sustainable strategy. Vitess addresses this problem through sharding, which can scale indefinitely.
+* High availability: Vitess has native capability for detecting primary failures and performing a failover to a new primary within seconds of failure detection. This is usually sufficient for most applications.
+* Low-latency geographically distributed writes: This is one case that is not addressed by Vitess. The current recommendation is to absorb the latency cost of long-distance round-trips for writes. If the data distribution allows, you still have the option of sharding based on geographic affinity. You can then setup primaries for different shards to be in different geographic locations. This way, most of the primary writes can still be local.
+
+## Multi-cell
+
+Vitess is meant to run in multiple data centers / regions / cells. In this part, we'll use "cell" to mean a set of servers that are very close together, and share the same regional availability.
+
+A cell typically contains a set of tablets, a vtgate pool, and app servers that use the Vitess cluster. With Vitess, all components can be configured and brought up as needed:
+
+* The primary for a shard can be in any cell. If cross-cell primary access is required, vtgate can be configured to do so easily (by passing the cell that contains the primary as a cell to watch).
+* It is not uncommon to have the cells that can contain the primary be more provisioned than read-only serving cells. These *primary-capable* cells may need one more replica to handle a possible failover, while still maintaining the same replica serving capacity.
+* Failing over from a primary in one cell to a primary in a different cell is no different than a local failover. It has an implication on traffic and latency, but if the application traffic also gets re-directed to the new cell, the end result is stable.
+* It is also possible to have some shards with a primary in one cell, and some other shards with their primary in another cell. vtgate will just route the traffic to the right place, incurring extra latency cost only on the remote access. For instance, creating U.S. user records in a database with primaries in the U.S. and European user records in a database with primaries in Europe is easy to do. Replicas can exist in every cell anyway, and serve the replica traffic quickly.
+* Replica serving cells are a good compromise to reduce user-visible latency: they only contain replica servers, and primary access is always done remotely. If the application profile is mostly reads, this works really well.
+* Not all cells need `rdonly` (or batch) instances. Only the cells that run batch jobs, or OLAP jobs, really need them.
+
+Note that Vitess uses local-cell data first, and is very resilient to any cell going down (most of our processes handle that case gracefully).
diff --git a/content/en/docs/21.0/overview/supported-databases.md b/content/en/docs/21.0/overview/supported-databases.md
new file mode 100644
index 000000000..f7c3a6117
--- /dev/null
+++ b/content/en/docs/21.0/overview/supported-databases.md
@@ -0,0 +1,29 @@
+---
+title: Supported Databases
+weight: 2
+featured: true
+---
+
+## Supported Databases In Vitess
+
+Vitess deploys, scales and manages clusters of open-source SQL database instances. Currently, Vitess supports the [MySQL](https://www.mysql.com/) and [Percona Server for MySQL](https://www.percona.com/software/mysql-database/percona-server) databases.
+
+The [VTGate](../../concepts/vtgate/) proxy server advertises its version as MySQL 8.0.
+
+### MySQL 8.0
+
+Vitess supports the core features of MySQL 8.0.\*,
+with [some limitations](../../reference/compatibility/mysql-compatibility/). Vitess also
+supports [Percona Server for MySQL](https://www.percona.com/software/mysql-database/percona-server) 8.0.\*.
+
+## Supported Databases For Imports
+
+Vitess supports importing from a wide range of databases that include:
+
+- [MySQL](https://www.mysql.com/) version 5.7 to 8.0
+- [Percona Server for MySQL](https://www.percona.com/software/mysql-database/percona-server) version 5.7 to 8.0
+- [MariaDB](https://mariadb.com) versions 10.10+
+
+## See also
+
++ [MySQL Compatibility](../../reference/compatibility/mysql-compatibility/)
diff --git a/content/en/docs/21.0/overview/whatisvitess.md b/content/en/docs/21.0/overview/whatisvitess.md
new file mode 100644
index 000000000..4dc39d80f
--- /dev/null
+++ b/content/en/docs/21.0/overview/whatisvitess.md
@@ -0,0 +1,69 @@
+---
+title: What Is Vitess
+weight: 1
+featured: true
+---
+
+Vitess is a database solution for deploying, scaling and managing large clusters of open-source database instances. It currently supports MySQL and Percona Server for MySQL. It's architected to run as effectively in a public or private cloud architecture as it does on dedicated hardware. It combines and extends many important SQL features with the scalability of a NoSQL database. Vitess can help you with the following problems:
+
+1. Scaling a SQL database by allowing you to shard it, while keeping application changes to a minimum.
+2. Migrating from bare-metal or VMs to a private or public cloud.
+3. Deploying and managing a large number of SQL database instances.
+
+Vitess includes compliant JDBC and Go database drivers using a native query protocol. Additionally, it implements the MySQL server protocol which is compatible with virtually any other language.
+
+Vitess served all YouTube database traffic for over five years. Many enterprises have now adopted Vitess for their production needs.
+
+## Features
+
+* Performance
+ - Connection pooling - Multiplex front-end application queries onto a pool of MySQL connections to optimize performance.
+ - Query de-duping – Reuse results of an in-flight query for any identical requests received while the in-flight query was still executing.
+ - Transaction manager – Limit number of concurrent transactions and manage timeouts to optimize overall throughput.
+
+* Protection
+ - Query rewriting and sanitization – Add limits and avoid non-deterministic updates.
+ - Query blocking – Customize rules to prevent potentially problematic queries from hitting your database.
+ - Query killing – Terminate queries that take too long to return data.
+ - Table ACLs – Specify access control lists (ACLs) for tables based on the connected user.
+
+* Monitoring
+ - Performance analysis tools let you monitor, diagnose, and analyze your database performance.
+
+* Topology Management Tools
+ - Cluster management tools (handles planned and unplanned failovers)
+ - Web-based management GUI
+ - Designed to work in multiple data centers / regions
+
+* Sharding
+ - Virtually seamless dynamic re-sharding
+ - Vertical and Horizontal sharding support
+ - Multiple sharding schemes, with the ability to plug-in custom ones
+
+## Comparisons to other storage options
+
+The following sections compare Vitess to two common alternatives, a vanilla MySQL implementation and a NoSQL implementation.
+
+### Vitess vs. Vanilla MySQL
+
+Vitess improves a vanilla MySQL implementation in several ways:
+
+| Vanilla MySQL | Vitess |
+|:--|:--|
+| Every MySQL connection has a memory overhead that ranges between 256KB and almost 3MB, depending on which MySQL release you're using. As your user base grows, you need to add RAM to support additional connections, but the RAM does not contribute to faster queries. In addition, there is a significant CPU cost associated with obtaining the connections. | Vitess creates very lightweight connections. Vitess' connection pooling feature uses Go's concurrency support to map these lightweight connections to a small pool of MySQL connections. As such, Vitess can easily handle thousands of connections. |
+| Poorly written queries, such as those that don't set a LIMIT, can negatively impact database performance for all users. | Vitess employs a SQL parser that uses a configurable set of rules to rewrite queries that might hurt database performance. |
+| Sharding is a process of partitioning your data to improve scalability and performance. MySQL lacks native sharding support, requiring you to write sharding code and embed sharding logic in your application. | Vitess supports a variety of sharding schemes. It can also migrate tables into different databases and scale the number of shards up or down. These functions are performed non-intrusively, completing most data transitions with just a few seconds of read-only downtime. |
+| A MySQL cluster using replication for availability has a primary database and a few replicas. If the primary fails, a replica should become the new primary. This requires you to manage the database lifecycle and communicate the current system state to your application. | Vitess helps to manage the lifecycle of your database servers. It supports and automatically handles various scenarios, including primary failure detection and recovery. It also has support for data backups and restores. |
+| A MySQL cluster can have custom database configurations for different workloads, like a primary database for writes, fast read-only replicas for web clients, slower read-only replicas for batch jobs, and so forth. If the database has horizontal sharding, the setup is repeated for each shard, and the app needs baked-in logic to know how to find the right database. | Vitess uses a topology backed by a consistent data store, like etcd or ZooKeeper. This means the cluster view is always up-to-date and consistent for different clients. Vitess also provides a proxy that routes queries efficiently to the most appropriate MySQL instance. |
+
+
+### Vitess vs. NoSQL
+
+If you're considering a NoSQL solution primarily because of concerns about the scalability of MySQL, Vitess might be a more appropriate choice for your application. While NoSQL provides great support for unstructured data, Vitess still offers several benefits not available in NoSQL datastores:
+
+| NoSQL | Vitess |
+|:--|:--|
+| NoSQL databases do not define relationships between database tables, and only support a subset of the SQL language. | Vitess is not a simple key-value store. It supports complex query semantics such as where clauses, JOINS, aggregation functions, and more. |
+| NoSQL datastores do not usually support transactions. | Vitess supports transactions. |
+| NoSQL solutions have custom APIs, leading to custom architectures, applications, and tools. | Vitess adds very little variance to MySQL, a database that most people are already accustomed to working with. |
+| NoSQL solutions provide limited support for database indexes compared to MySQL. | Vitess allows you to use all of MySQL's indexing functionality to optimize query performance. |
diff --git a/content/en/docs/21.0/reference/_index.md b/content/en/docs/21.0/reference/_index.md
new file mode 100644
index 000000000..3d086453c
--- /dev/null
+++ b/content/en/docs/21.0/reference/_index.md
@@ -0,0 +1,7 @@
+---
+title: Reference
+description: Detailed information about specific Vitess functionality
+weight: 5
+aliases: ['/docs/advanced/']
+---
+
diff --git a/content/en/docs/21.0/reference/backup-and-restore/_index.md b/content/en/docs/21.0/reference/backup-and-restore/_index.md
new file mode 100644
index 000000000..c072654b6
--- /dev/null
+++ b/content/en/docs/21.0/reference/backup-and-restore/_index.md
@@ -0,0 +1,7 @@
+---
+title: Backup and Restore
+description: "Backup and Restore Reference"
+weight: 10
+aliases: ['/docs/reference/backup-and-restore/']
+skip_sections: true
+---
diff --git a/content/en/docs/21.0/reference/backup-and-restore/metrics.md b/content/en/docs/21.0/reference/backup-and-restore/metrics.md
new file mode 100644
index 000000000..57d89f091
--- /dev/null
+++ b/content/en/docs/21.0/reference/backup-and-restore/metrics.md
@@ -0,0 +1,128 @@
+---
+title: Metrics
+description: Metrics related to backup and restore functionality
+weight: 10
+---
+
+Backup and restore operations export several metrics using the expvars interface. These are available at the `/debug/vars` endpoint of Vtbackup's and VTTablet's http status pages. [More details can be found here](../../features/monitoring/#3-push-based-metrics-system).
+
+## Backup metrics
+
+Metrics related to backup operations are available in both Vtbackup and VTTablet.
+
+#### BackupBytes, BackupCount, BackupDurationNanoseconds
+
+Depending on the Backup Engine and Backup Storage in-use, a backup may be a complex pipeline of operations, including but not limited to:
+
+ * Reading files from disk.
+ * Compressing files.
+ * Uploading compress files to cloud object storage.
+
+These operations are counted and timed, and the number of bytes consumed or produced by each stage of the pipeline are counted as well.
+
+## Restore metrics
+
+Metrics related to restore operations are available in both Vtbackup and VTTablet.
+
+#### RestoreBytes, RestoreCount, RestoreDurationNanoseconds
+
+Depending on the Backup Engine and Backup Storage in-use, a restore may be a complex pipeline of operations, including but not limited to:
+
+ * Downloading compressed files from cloud object storage.
+ * Decompressing files.
+ * Writing decompressed files to disk.
+
+These operations are counted and timed, and the number of bytes consumed or produced by each stage of the pipeline are counted as well.
+
+#### RestoredBackupTime, RestorePosition
+
+_RestoredBackupTime_ captures the timestamp associated with the backup from which the current process was restored. _RestorePosition_ captures the GTID position associated with that backup.
+
+## Vtbackup metrics
+
+Vtbackup exports some metrics which are not available elsewhere.
+
+#### DurationByPhaseSeconds
+
+Vtbackup fetches the last backup, restores it to an empty mysql installation, replicates recent changes into that installation, and then takes a backup of that installation.
+
+_DurationByPhaseSeconds_ exports timings for these individual phases.
+
+hU!Yt4h39lFac#2&AS0RMExk#yo>X70S9~uR{V~+Z
z$bJg$TE{j43hK2qvrPc0n5usf0A7v8J4IXYIDgQ0$Q#gPZ&b8((X?L|k-z3RS@Oyu
z?Uly;qRws+XC*ZmTboRI$vZJ>leW^g72FzckCrKEk#4tG9