diff --git a/docs/content/latest/develop/client-drivers/java.md b/docs/content/latest/develop/client-drivers/java.md
index d79f1030150..f1fe1069181 100644
--- a/docs/content/latest/develop/client-drivers/java.md
+++ b/docs/content/latest/develop/client-drivers/java.md
@@ -13,33 +13,24 @@ menu:
-
- {{% includeMarkdown "cassandra/java.md" /%}}
-
-
- {{% includeMarkdown "redis/java.md" /%}}
-
-
+
{{% includeMarkdown "ysql/java.md" /%}}
+
+ {{% includeMarkdown "ycql/java.md" /%}}
+
diff --git a/docs/content/latest/develop/client-drivers/nodejs.md b/docs/content/latest/develop/client-drivers/nodejs.md
index 4d42e6ddb82..65c6469e301 100644
--- a/docs/content/latest/develop/client-drivers/nodejs.md
+++ b/docs/content/latest/develop/client-drivers/nodejs.md
@@ -13,33 +13,24 @@ menu:
-
- {{% includeMarkdown "cassandra/nodejs.md" /%}}
-
-
- {{% includeMarkdown "redis/nodejs.md" /%}}
-
-
+
{{% includeMarkdown "ysql/nodejs.md" /%}}
+
+ {{% includeMarkdown "ycql/nodejs.md" /%}}
+
diff --git a/docs/content/latest/develop/client-drivers/python.md b/docs/content/latest/develop/client-drivers/python.md
index 695a9e3c51b..26fe38c85f0 100644
--- a/docs/content/latest/develop/client-drivers/python.md
+++ b/docs/content/latest/develop/client-drivers/python.md
@@ -13,33 +13,24 @@ menu:
-
- {{% includeMarkdown "cassandra/python.md" /%}}
-
-
- {{% includeMarkdown "redis/python.md" /%}}
-
-
+
{{% includeMarkdown "ysql/python.md" /%}}
+
+ {{% includeMarkdown "ycql/python.md" /%}}
+
diff --git a/docs/content/latest/develop/client-drivers/redis/scala.md b/docs/content/latest/develop/client-drivers/redis/scala.md
deleted file mode 100644
index bbd4fa974c3..00000000000
--- a/docs/content/latest/develop/client-drivers/redis/scala.md
+++ /dev/null
@@ -1,4 +0,0 @@
-
-## Installation
-
-Coming soon.
\ No newline at end of file
diff --git a/docs/content/latest/develop/client-drivers/redis/spark.md b/docs/content/latest/develop/client-drivers/redis/spark.md
deleted file mode 100644
index bbd4fa974c3..00000000000
--- a/docs/content/latest/develop/client-drivers/redis/spark.md
+++ /dev/null
@@ -1,4 +0,0 @@
-
-## Installation
-
-Coming soon.
\ No newline at end of file
diff --git a/docs/content/latest/develop/client-drivers/ruby.md b/docs/content/latest/develop/client-drivers/ruby.md
index 7a744745264..552ecc13c69 100644
--- a/docs/content/latest/develop/client-drivers/ruby.md
+++ b/docs/content/latest/develop/client-drivers/ruby.md
@@ -14,7 +14,7 @@ menu:
-
-
+
YSQL
diff --git a/docs/content/latest/develop/client-drivers/scala.md b/docs/content/latest/develop/client-drivers/scala.md
deleted file mode 100644
index e9ada132e34..00000000000
--- a/docs/content/latest/develop/client-drivers/scala.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: Develop Scala Apps
-linkTitle: Develop Scala Apps
-aliases:
- - /develop/client-drivers/scala/
----
-
-
-
-
-
- {{% includeMarkdown "cassandra/scala.md" /%}}
-
-
- {{% includeMarkdown "redis/scala.md" /%}}
-
-
-
- {{% includeMarkdown "cassandra/spark.md" /%}}
-
-
- {{% includeMarkdown "redis/spark.md" /%}}
-
-
- {{% includeMarkdown "cassandra/acid-transactions.md" /%}}
+ {{% includeMarkdown "ycql/acid-transactions.md" /%}}
diff --git a/docs/content/latest/develop/learn/aggregations.md b/docs/content/latest/develop/learn/aggregations.md
index 269559d0c7c..52c9831625c 100644
--- a/docs/content/latest/develop/learn/aggregations.md
+++ b/docs/content/latest/develop/learn/aggregations.md
@@ -22,6 +22,6 @@ menu:
- {{% includeMarkdown "cassandra/aggregations.md" /%}}
+ {{% includeMarkdown "ycql/aggregations.md" /%}}
diff --git a/docs/content/latest/develop/learn/batch-operations.md b/docs/content/latest/develop/learn/batch-operations.md
index 27d14fe8620..eb52b45f8a9 100644
--- a/docs/content/latest/develop/learn/batch-operations.md
+++ b/docs/content/latest/develop/learn/batch-operations.md
@@ -24,6 +24,6 @@ Batch operations is the ability to send a set of operations as one operation (RP
- {{% includeMarkdown "cassandra/batch-operations.md" /%}}
+ {{% includeMarkdown "ycql/batch-operations.md" /%}}
diff --git a/docs/content/latest/develop/learn/cassandra/acid-transactions.md b/docs/content/latest/develop/learn/cassandra/acid-transactions.md
deleted file mode 100644
index a1ca7f70b61..00000000000
--- a/docs/content/latest/develop/learn/cassandra/acid-transactions.md
+++ /dev/null
@@ -1,113 +0,0 @@
-
-## Creating the table
-
-The table should be created with the `transactions` property enabled. The statement should look something as follows.
-
-```sql
-CREATE TABLE IF NOT EXISTS (...) WITH transactions = { 'enabled' : true };
-```
-
-### Java example
-
-Here is an example of how to create a simple key-value table which has two columns with transactions enabled.
-
-```java
-String create_stmt =
- String.format("CREATE TABLE IF NOT EXISTS %s (k varchar, v varchar, primary key (k)) " +
- "WITH transactions = { 'enabled' : true };",
- tablename);
-```
-
-
-## Inserting or updating data
-
-You can insert data by performing the sequence of commands inside a `BEGIN TRANSACTION` and `END TRANSACTION` block.
-
-```sql
-BEGIN TRANSACTION
- statement 1
- statement 2
-END TRANSACTION;
-```
-
-
-### Java example
-
-Here is a code snippet of how you would insert data into this table.
-
-```java
-// Insert two key values, (key1, value1) and (key2, value2) as a transaction.
-String create_stmt =
- String.format("BEGIN TRANSACTION" +
- " INSERT INTO %s (k, v) VALUES (%s, %s);" +
- " INSERT INTO %s (k, v) VALUES (%s, %s);" +
- "END TRANSACTION;",
- tablename, key1, value1,
- tablename, key2, value2;
-```
-
-
-## Prepare-bind transactions
-
-You can prepare statements with transactions and bind variables to the prepared statements when executing the query.
-
-### Java example
-
-```java
-String create_stmt =
- String.format("BEGIN TRANSACTION" +
- " INSERT INTO %s (k, v) VALUES (:k1, :v1);" +
- " INSERT INTO %s (k, v) VALUES (:k1, :v2);" +
- "END TRANSACTION;",
- tablename, key1, value1,
- tablename, key2, value2;
-PreparedStatement pstmt = client.prepare(create_stmt);
-
-...
-
-BoundStatement txn1 = pstmt.bind().setString("k1", key1)
- .setString("v1", value1)
- .setString("k2", key2)
- .setString("v2", value2);
-
-ResultSet resultSet = client.execute(txn1);
-```
-
-## Sample Java Application
-
-You can find a working example of using transactions with YugaByte in our [sample applications](../../../quick-start/run-sample-apps/). This application writes out string keys in pairs, with each pair of keys having the same value written as a transaction. There are multiple readers and writers that update and read these pair of keys. The number of reads and writes to perform can be specified as a parameter.
-
-Here is how you can try out this sample application.
-
-```sh
-Usage:
- java -jar yb-sample-apps.jar \
- --workload CassandraTransactionalKeyValue \
- --nodes 127.0.0.1:9042
-
- Other options (with default values):
- [ --num_unique_keys 1000000 ]
- [ --num_reads -1 ]
- [ --num_writes -1 ]
- [ --value_size 0 ]
- [ --num_threads_read 24 ]
- [ --num_threads_write 2 ]
-```
-
-
-Browse the [Java source code for the batch application](https://github.com/YugaByte/yugabyte-db/blob/master/java/yb-loadtester/src/main/java/com/yugabyte/sample/apps/CassandraTransactionalKeyValue.java) to see how everything fits together.
-
-## Note on Linearizability
-
-By default, the original Cassandra Java driver and the YugaByte DB Cassandra Java driver use `com.datastax.driver.core.policies.DefaultRetryPolicy`
-which can retry requests upon timeout on client side.
-
-Automatic retries can break linearizability of operations from the client point of view.
-Therefore we have added `com.yugabyte.driver.core.policies.NoRetryOnClientTimeoutPolicy` which inherits behavior from DefaultRetryPolicy with one
-exception - it results in an error in case the operation times out (with the `OperationTimedOutException`).
-
-Under network partitions, this can lead to the case when client gets a successful response to retried request and treats
-the operation as completed, but the value might get overwritten by an older operation due to retries.
-
-To avoid such linearizability issues, use `com.yugabyte.driver.core.policies.NoRetryOnClientTimeoutPolicy` and handle
-client timeouts in the application layer.
diff --git a/docs/content/latest/develop/learn/conditional-updates.md b/docs/content/latest/develop/learn/conditional-updates.md
index 133cdd7c134..8e0d1b0412a 100644
--- a/docs/content/latest/develop/learn/conditional-updates.md
+++ b/docs/content/latest/develop/learn/conditional-updates.md
@@ -17,6 +17,6 @@ aliases:
- {{% includeMarkdown "cassandra/conditional-updates.md" /%}}
+ {{% includeMarkdown "ycql/conditional-updates.md" /%}}
diff --git a/docs/content/latest/develop/learn/data-modeling.md b/docs/content/latest/develop/learn/data-modeling.md
index 1c5374de4b5..ace8aa4fd9c 100644
--- a/docs/content/latest/develop/learn/data-modeling.md
+++ b/docs/content/latest/develop/learn/data-modeling.md
@@ -4,6 +4,7 @@ linkTitle: 2. Data Modeling
description: Data Modeling
aliases:
- /develop/learn/data-modeling/
+ - /latest/explore/transactional/secondary-indexes/
menu:
latest:
identifier: data-modeling
@@ -24,6 +25,6 @@ Data modeling is a process that involves identifying the entities (items to be s
- {{% includeMarkdown "cassandra/data-modeling.md" /%}}
+ {{% includeMarkdown "ycql/data-modeling.md" /%}}
diff --git a/docs/content/latest/develop/learn/data-types.md b/docs/content/latest/develop/learn/data-types.md
index cb3eef58ac7..ce81abdd608 100644
--- a/docs/content/latest/develop/learn/data-types.md
+++ b/docs/content/latest/develop/learn/data-types.md
@@ -4,6 +4,7 @@ linkTitle: 3. Data Types
description: Data Types
aliases:
- /develop/learn/data-types/
+ - /latest/explore/transactional/json-documents/
menu:
latest:
identifier: data-types
@@ -22,6 +23,6 @@ menu:
- {{% includeMarkdown "cassandra/data-types.md" /%}}
+ {{% includeMarkdown "ycql/data-types.md" /%}}
diff --git a/docs/content/latest/develop/learn/reads-writes.md b/docs/content/latest/develop/learn/reads-writes.md
index 5f65afd8f52..95735eafaa5 100644
--- a/docs/content/latest/develop/learn/reads-writes.md
+++ b/docs/content/latest/develop/learn/reads-writes.md
@@ -16,6 +16,6 @@ aliases:
- {{% includeMarkdown "cassandra/reads-writes.md" /%}}
+ {{% includeMarkdown "ycql/reads-writes.md" /%}}
diff --git a/docs/content/latest/develop/learn/timeseries-data.md b/docs/content/latest/develop/learn/timeseries-data.md
index 4cba6b750e2..9438ce5d6e0 100644
--- a/docs/content/latest/develop/learn/timeseries-data.md
+++ b/docs/content/latest/develop/learn/timeseries-data.md
@@ -23,9 +23,9 @@ aliases:
- {{% includeMarkdown "cassandra/timeseries-data.md" /%}}
+ {{% includeMarkdown "ycql/timeseries-data.md" /%}}
- {{% includeMarkdown "redis/timeseries-data.md" /%}}
+ {{% includeMarkdown "yedis/timeseries-data.md" /%}}
diff --git a/docs/content/latest/develop/learn/ttl-data-expiry.md b/docs/content/latest/develop/learn/ttl-data-expiry.md
index bfec8f457de..9f00cf5de6e 100644
--- a/docs/content/latest/develop/learn/ttl-data-expiry.md
+++ b/docs/content/latest/develop/learn/ttl-data-expiry.md
@@ -22,9 +22,9 @@ aliases:
- {{% includeMarkdown "cassandra/ttl-data-expiry.md" /%}}
+ {{% includeMarkdown "ycql/ttl-data-expiry.md" /%}}
- {{% includeMarkdown "redis/ttl-data-expiry.md" /%}}
+ {{% includeMarkdown "yedis/ttl-data-expiry.md" /%}}
diff --git a/docs/content/latest/explore/transactional/kubernetes/transactions.md b/docs/content/latest/develop/learn/ycql/acid-transactions.md
similarity index 54%
rename from docs/content/latest/explore/transactional/kubernetes/transactions.md
rename to docs/content/latest/develop/learn/ycql/acid-transactions.md
index 7ea011c3496..ad669925c71 100644
--- a/docs/content/latest/explore/transactional/kubernetes/transactions.md
+++ b/docs/content/latest/develop/learn/ycql/acid-transactions.md
@@ -1,40 +1,107 @@
-## 1. Setup - create universe and table
-If you have a previously running local universe, destroy it using the following.
+## Creating the table
-```sh
-$ kubectl delete -f yugabyte-statefulset.yaml
+The table should be created with the `transactions` property enabled. The statement should look something as follows.
+
+```sql
+CREATE TABLE IF NOT EXISTS (...) WITH transactions = { 'enabled' : true };
```
-Start a new local cluster - by default, this will create a 3 node universe with a replication factor of 3.
+### Java example
-```sh
-$ kubectl apply -f yugabyte-statefulset.yaml
+Here is an example of how to create a simple key-value table which has two columns with transactions enabled.
+
+```java
+String create_stmt =
+ String.format("CREATE TABLE IF NOT EXISTS %s (k varchar, v varchar, primary key (k)) " +
+ "WITH transactions = { 'enabled' : true };",
+ tablename);
```
-Check the Kubernetes dashboard to see the 3 yb-tserver and 3 yb-master pods representing the 3 nodes of the cluster.
-```sh
-$ minikube dashboard
+## Inserting or updating data
+
+You can insert data by performing the sequence of commands inside a `BEGIN TRANSACTION` and `END TRANSACTION` block.
+
+```sql
+BEGIN TRANSACTION
+ statement 1
+ statement 2
+END TRANSACTION;
```
-
-## 2. Create a table for transactions
+### Java example
-Connect to cqlsh on node 1.
+Here is a code snippet of how you would insert data into this table.
-```sh
-$ kubectl exec -it yb-tserver-0 /home/yugabyte/bin/cqlsh
+```java
+// Insert two key values, (key1, value1) and (key2, value2) as a transaction.
+String create_stmt =
+ String.format("BEGIN TRANSACTION" +
+ " INSERT INTO %s (k, v) VALUES (%s, %s);" +
+ " INSERT INTO %s (k, v) VALUES (%s, %s);" +
+ "END TRANSACTION;",
+ tablename, key1, value1,
+ tablename, key2, value2;
```
+
+## Prepare-bind transactions
+
+You can prepare statements with transactions and bind variables to the prepared statements when executing the query.
+
+### Java example
+
+```java
+String create_stmt =
+ String.format("BEGIN TRANSACTION" +
+ " INSERT INTO %s (k, v) VALUES (:k1, :v1);" +
+ " INSERT INTO %s (k, v) VALUES (:k1, :v2);" +
+ "END TRANSACTION;",
+ tablename, key1, value1,
+ tablename, key2, value2;
+PreparedStatement pstmt = client.prepare(create_stmt);
+
+...
+
+BoundStatement txn1 = pstmt.bind().setString("k1", key1)
+ .setString("v1", value1)
+ .setString("k2", key2)
+ .setString("v2", value2);
+
+ResultSet resultSet = client.execute(txn1);
```
-Connected to local cluster at 127.0.0.1:9042.
-[cqlsh 5.0.1 | Cassandra 3.9-SNAPSHOT | CQL spec 3.4.2 | Native protocol v4]
-Use HELP for help.
-cqlsh>
+
+## Sample Java Application
+
+You can find a working example of using transactions with YugaByte in our [sample applications](../../../quick-start/run-sample-apps/). This application writes out string keys in pairs, with each pair of keys having the same value written as a transaction. There are multiple readers and writers that update and read these pair of keys. The number of reads and writes to perform can be specified as a parameter.
+
+Here is how you can try out this sample application.
+
+```sh
+Usage:
+ java -jar yb-sample-apps.jar \
+ --workload CassandraTransactionalKeyValue \
+ --nodes 127.0.0.1:9042
+
+ Other options (with default values):
+ [ --num_unique_keys 1000000 ]
+ [ --num_reads -1 ]
+ [ --num_writes -1 ]
+ [ --value_size 0 ]
+ [ --num_threads_read 24 ]
+ [ --num_threads_write 2 ]
```
+
+Browse the [Java source code for the batch application](https://github.com/YugaByte/yugabyte-db/blob/master/java/yb-loadtester/src/main/java/com/yugabyte/sample/apps/CassandraTransactionalKeyValue.java) to see how everything fits together.
+
+
+## Example with cqlsh
+
+### Create keyspace and table
+
Create a keyspace.
```sql
@@ -67,7 +134,7 @@ where keyspace_name='banking' AND table_name = 'accounts';
(1 rows)
```
-## 3. Insert sample data
+### Insert sample data
Let us seed this table with some sample data.
@@ -116,8 +183,7 @@ cqlsh> SELECT SUM(balance) as smiths_balance FROM banking.accounts WHERE account
```
-
-## 4. Execute a transaction
+### Execute a transaction
Here are a couple of examples of executing transactions.
@@ -168,6 +234,7 @@ from banking.accounts where account_name='John';
John | savings | 800 | 1517898028890171
```
+
Now let us say John transfers the $200 from his checking account to Smith's checking account. We can accomplish that with the following transaction.
```sql
@@ -177,6 +244,7 @@ BEGIN TRANSACTION
END TRANSACTION;
```
+
We can verify the transfer was made as we intended, and also verify that the time at which the two accounts were updated are identical by performing the following query.
```sql
@@ -215,10 +283,13 @@ cqlsh> SELECT SUM(balance) as smiths_balance FROM banking.accounts WHERE account
2250
```
-## 5. Clean up (optional)
-Optionally, you can shutdown the local cluster created in Step 1.
+## Note on Linearizability
-```sh
-$ kubectl delete -f yugabyte-statefulset.yaml
-```
+By default, the original Cassandra Java driver and the YugaByte DB Cassandra Java driver use `com.datastax.driver.core.policies.DefaultRetryPolicy` which can retry requests upon timeout on client side.
+
+Automatic retries can break linearizability of operations from the client point of view. Therefore we have added `com.yugabyte.driver.core.policies.NoRetryOnClientTimeoutPolicy` which inherits behavior from DefaultRetryPolicy with one exception - it results in an error in case the operation times out (with the `OperationTimedOutException`).
+
+Under network partitions, this can lead to the case when client gets a successful response to retried request and treats the operation as completed, but the value might get overwritten by an older operation due to retries.
+
+To avoid such linearizability issues, use `com.yugabyte.driver.core.policies.NoRetryOnClientTimeoutPolicy` and handle client timeouts in the application layer.
diff --git a/docs/content/latest/develop/learn/cassandra/aggregations.md b/docs/content/latest/develop/learn/ycql/aggregations.md
similarity index 100%
rename from docs/content/latest/develop/learn/cassandra/aggregations.md
rename to docs/content/latest/develop/learn/ycql/aggregations.md
diff --git a/docs/content/latest/develop/learn/cassandra/batch-operations.md b/docs/content/latest/develop/learn/ycql/batch-operations.md
similarity index 100%
rename from docs/content/latest/develop/learn/cassandra/batch-operations.md
rename to docs/content/latest/develop/learn/ycql/batch-operations.md
diff --git a/docs/content/latest/develop/learn/cassandra/conditional-updates.md b/docs/content/latest/develop/learn/ycql/conditional-updates.md
similarity index 100%
rename from docs/content/latest/develop/learn/cassandra/conditional-updates.md
rename to docs/content/latest/develop/learn/ycql/conditional-updates.md
diff --git a/docs/content/latest/develop/learn/cassandra/data-modeling.md b/docs/content/latest/develop/learn/ycql/data-modeling.md
similarity index 100%
rename from docs/content/latest/develop/learn/cassandra/data-modeling.md
rename to docs/content/latest/develop/learn/ycql/data-modeling.md
diff --git a/docs/content/latest/develop/learn/cassandra/data-types.md b/docs/content/latest/develop/learn/ycql/data-types.md
similarity index 100%
rename from docs/content/latest/develop/learn/cassandra/data-types.md
rename to docs/content/latest/develop/learn/ycql/data-types.md
diff --git a/docs/content/latest/develop/learn/cassandra/reads-writes.md b/docs/content/latest/develop/learn/ycql/reads-writes.md
similarity index 100%
rename from docs/content/latest/develop/learn/cassandra/reads-writes.md
rename to docs/content/latest/develop/learn/ycql/reads-writes.md
diff --git a/docs/content/latest/develop/learn/cassandra/timeseries-data.md b/docs/content/latest/develop/learn/ycql/timeseries-data.md
similarity index 100%
rename from docs/content/latest/develop/learn/cassandra/timeseries-data.md
rename to docs/content/latest/develop/learn/ycql/timeseries-data.md
diff --git a/docs/content/latest/develop/learn/cassandra/ttl-data-expiry.md b/docs/content/latest/develop/learn/ycql/ttl-data-expiry.md
similarity index 100%
rename from docs/content/latest/develop/learn/cassandra/ttl-data-expiry.md
rename to docs/content/latest/develop/learn/ycql/ttl-data-expiry.md
diff --git a/docs/content/latest/develop/learn/redis/batch-operations.md b/docs/content/latest/develop/learn/yedis/batch-operations.md
similarity index 100%
rename from docs/content/latest/develop/learn/redis/batch-operations.md
rename to docs/content/latest/develop/learn/yedis/batch-operations.md
diff --git a/docs/content/latest/develop/learn/redis/counters-and-aggregations.md b/docs/content/latest/develop/learn/yedis/counters-and-aggregations.md
similarity index 100%
rename from docs/content/latest/develop/learn/redis/counters-and-aggregations.md
rename to docs/content/latest/develop/learn/yedis/counters-and-aggregations.md
diff --git a/docs/content/latest/develop/learn/redis/timeseries-data.md b/docs/content/latest/develop/learn/yedis/timeseries-data.md
similarity index 100%
rename from docs/content/latest/develop/learn/redis/timeseries-data.md
rename to docs/content/latest/develop/learn/yedis/timeseries-data.md
diff --git a/docs/content/latest/develop/learn/redis/ttl-data-expiry.md b/docs/content/latest/develop/learn/yedis/ttl-data-expiry.md
similarity index 100%
rename from docs/content/latest/develop/learn/redis/ttl-data-expiry.md
rename to docs/content/latest/develop/learn/yedis/ttl-data-expiry.md
diff --git a/docs/content/latest/develop/learn/redis/user-defined-types.md b/docs/content/latest/develop/learn/yedis/user-defined-types.md
similarity index 100%
rename from docs/content/latest/develop/learn/redis/user-defined-types.md
rename to docs/content/latest/develop/learn/yedis/user-defined-types.md
diff --git a/docs/content/latest/develop/realworld-apps/retail-analytics.md b/docs/content/latest/develop/realworld-apps/retail-analytics.md
index a9a13f15fdd..6d80b67cd56 100644
--- a/docs/content/latest/develop/realworld-apps/retail-analytics.md
+++ b/docs/content/latest/develop/realworld-apps/retail-analytics.md
@@ -15,7 +15,7 @@ showAsideToc: true
## 1. Start Local Cluster with YSQL API Enabled
-Follow [Quick Start](../../../quick-start/) instructions to run a local YugaByte DB cluster. Test YugaByte DB's PostgreSQL compatible YSQL API as [documented](../../../quick-start/test-postgresql/) so that you can confirm that you have the YSQL service running on `localhost:5433`.
+Follow [Quick Start](../../../quick-start/) instructions to run a local YugaByte DB cluster. Test the YSQL API as [documented](../../../quick-start/test-ysql/) so that you can confirm that you have the YSQL service running on `localhost:5433`.
## 2. Load Data
diff --git a/docs/content/latest/develop/tools/_index.html b/docs/content/latest/develop/tools/_index.html
index d374bcc9f11..7a6a5122857 100644
--- a/docs/content/latest/develop/tools/_index.html
+++ b/docs/content/latest/develop/tools/_index.html
@@ -34,7 +34,7 @@
TablePlus
- A unified developer console for querying all the 3 APIs supported by YugaByte DB.
+ A unified developer console for querying all YugaByte DB APIs.
diff --git a/docs/content/latest/explore/_index.md b/docs/content/latest/explore/_index.md
index 7d04ef9973b..d5f64aa9eee 100644
--- a/docs/content/latest/explore/_index.md
+++ b/docs/content/latest/explore/_index.md
@@ -5,7 +5,10 @@ description: Explore Core Features
headcontent:
image: /images/section_icons/index/explore.png
aliases:
- - /explore/
+ - /latest/explore/cloud-native/
+ - /latest/explore/transactional/
+ - /latest/explore/high-performance/
+ - /latest/explore/planet-scale/
menu:
latest:
identifier: explore
@@ -16,63 +19,94 @@ menu:
{{< tip title="Tip" >}}You can use your [local cluster](../quick-start/) to explore all the core features of YugaByte DB.{{< /tip >}}
diff --git a/docs/content/latest/explore/planet-scale/auto-rebalancing.md b/docs/content/latest/explore/auto-rebalancing.md
similarity index 94%
rename from docs/content/latest/explore/planet-scale/auto-rebalancing.md
rename to docs/content/latest/explore/auto-rebalancing.md
index 571cce39b4a..5bc98b61731 100644
--- a/docs/content/latest/explore/planet-scale/auto-rebalancing.md
+++ b/docs/content/latest/explore/auto-rebalancing.md
@@ -1,15 +1,16 @@
---
title: Auto Rebalancing
-linkTitle: 3. Auto Rebalancing
+linkTitle: 5. Auto Rebalancing
description: Auto Rebalancing
aliases:
- /explore/auto-rebalancing/
- /latest/explore/auto-rebalancing/
+ - /latest/explore/planet-scale/auto-rebalancing/
menu:
latest:
identifier: auto-rebalancing
- parent: explore-planet-scale
- weight: 280
+ parent: explore
+ weight: 230
---
YugaByte DB automatically rebalances data into newly added nodes, so that the cluster can easily be expanded if more space is needed. In this tutorial, we will look at how YugaByte rebalances data while a workload is running. We will run a read-write workload using a pre-packaged sample application against a 3-node local universe with a replication factor of 3, and add nodes to it while the workload is running. We will then observe how the cluster rebalances its on-disk data as well as its memory footprint.
diff --git a/docs/content/latest/explore/planet-scale/auto-sharding.md b/docs/content/latest/explore/auto-sharding.md
similarity index 95%
rename from docs/content/latest/explore/planet-scale/auto-sharding.md
rename to docs/content/latest/explore/auto-sharding.md
index a7cd8254905..94663332e9e 100644
--- a/docs/content/latest/explore/planet-scale/auto-sharding.md
+++ b/docs/content/latest/explore/auto-sharding.md
@@ -1,15 +1,16 @@
---
title: Auto Sharding
-linkTitle: 2. Auto Sharding
+linkTitle: 4. Auto Sharding
description: Auto Sharding
aliases:
- /explore/auto-sharding/
- /latest/explore/auto-sharding/
+ - /latest/explore/planet-scale/auto-sharding/
menu:
latest:
identifier: auto-sharding
- parent: explore-planet-scale
- weight: 270
+ parent: explore
+ weight: 225
---
YugaByte DB automatically splits user tables into multiple shards, called **tablets**. The primary key for each row in the table uniquely determines the tablet the row lives in. For data distribution purposes, a hash based partitioning scheme is used. Read more about [how sharding works](../../../architecture/concepts/sharding/) in YugaByte DB.
diff --git a/docs/content/latest/explore/planet-scale/binary/auto-rebalancing.md b/docs/content/latest/explore/binary/auto-rebalancing.md
similarity index 100%
rename from docs/content/latest/explore/planet-scale/binary/auto-rebalancing.md
rename to docs/content/latest/explore/binary/auto-rebalancing.md
diff --git a/docs/content/latest/explore/planet-scale/binary/auto-sharding.md b/docs/content/latest/explore/binary/auto-sharding.md
similarity index 100%
rename from docs/content/latest/explore/planet-scale/binary/auto-sharding.md
rename to docs/content/latest/explore/binary/auto-sharding.md
diff --git a/docs/content/latest/explore/postgresql/binary/fault-tolerance.md b/docs/content/latest/explore/binary/fault-tolerance.md
similarity index 100%
rename from docs/content/latest/explore/postgresql/binary/fault-tolerance.md
rename to docs/content/latest/explore/binary/fault-tolerance.md
diff --git a/docs/content/latest/explore/planet-scale/binary/global-distribution.md b/docs/content/latest/explore/binary/global-distribution.md
similarity index 100%
rename from docs/content/latest/explore/planet-scale/binary/global-distribution.md
rename to docs/content/latest/explore/binary/global-distribution.md
diff --git a/docs/content/latest/explore/postgresql/binary/linear-scalability.md b/docs/content/latest/explore/binary/linear-scalability.md
similarity index 100%
rename from docs/content/latest/explore/postgresql/binary/linear-scalability.md
rename to docs/content/latest/explore/binary/linear-scalability.md
diff --git a/docs/content/latest/explore/cloud-native/binary/observability.md b/docs/content/latest/explore/binary/observability.md
similarity index 100%
rename from docs/content/latest/explore/cloud-native/binary/observability.md
rename to docs/content/latest/explore/binary/observability.md
diff --git a/docs/content/latest/explore/high-performance/binary/tunable-reads.md b/docs/content/latest/explore/binary/tunable-reads.md
similarity index 100%
rename from docs/content/latest/explore/high-performance/binary/tunable-reads.md
rename to docs/content/latest/explore/binary/tunable-reads.md
diff --git a/docs/content/latest/explore/cloud-native/_index.md b/docs/content/latest/explore/cloud-native/_index.md
deleted file mode 100644
index 458cca8839e..00000000000
--- a/docs/content/latest/explore/cloud-native/_index.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Explore Cloud Native Features
-linkTitle: Cloud Native
-description: Cloud Native
-headcontent:
-image: /images/section_icons/explore/cloud_native.png
-aliases:
- - /explore/cloud-native/
-menu:
- latest:
- identifier: explore-cloud-native
- parent: explore
- weight: 205
----
-
-{{< tip title="Cloud Native Definition" >}}
-Cloud native technologies empower organizations to build and run **scalable** applications in modern, **dynamic** environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
-
-These techniques enable loosely coupled systems that are **resilient**, **manageable**, and **observable**. Combined with robust **automation**, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
-
-> Provided By the [Cloud Native Computing Foundation](https://www.cncf.io/about/charter/)
-{{< /tip >}}
-
-YugaByte DB was architected ground-up with **cloud native** as one of its core design principles. This section explores some of the highlighted terms in the above formal definition.
-
-
-
-
\ No newline at end of file
diff --git a/docs/content/latest/explore/cloud-native/binary/fault-tolerance.md b/docs/content/latest/explore/cloud-native/binary/fault-tolerance.md
deleted file mode 100644
index bb96c09d5f6..00000000000
--- a/docs/content/latest/explore/cloud-native/binary/fault-tolerance.md
+++ /dev/null
@@ -1,227 +0,0 @@
-## 1. Setup - create universe and table
-
-If you have a previously running local universe, destroy it using the following.
-
-```sh
-$ ./bin/yb-ctl destroy
-```
-
-Start a new local universe with replication factor 5.
-
-```sh
-$ ./bin/yb-ctl --replication_factor 5 create
-```
-
-Connect to cqlsh on node 1.
-
-```sh
-$ ./bin/cqlsh 127.0.0.1
-```
-
-```sh
-Connected to local cluster at 127.0.0.1:9042.
-[cqlsh 5.0.1 | Cassandra 3.9-SNAPSHOT | CQL spec 3.4.2 | Native protocol v4]
-Use HELP for help.
-cqlsh>
-```
-
-Create a CQL keyspace and a table.
-
-```sql
-cqlsh> CREATE KEYSPACE users;
-```
-
-```sql
-cqlsh> CREATE TABLE users.profile (id bigint PRIMARY KEY,
- email text,
- password text,
- profile frozen
>);
-```
-
-
-## 2. Insert data through node 1
-
-Now insert some data by typing the following into cqlsh shell we joined above.
-
-```sql
-cqlsh> INSERT INTO users.profile (id, email, password, profile) VALUES
- (1000, 'james.bond@yugabyte.com', 'licensed2Kill',
- {'firstname': 'James', 'lastname': 'Bond', 'nickname': '007'}
- );
-```
-
-```sql
-cqlsh> INSERT INTO users.profile (id, email, password, profile) VALUES
- (2000, 'sherlock.holmes@yugabyte.com', 'itsElementary',
- {'firstname': 'Sherlock', 'lastname': 'Holmes'}
- );
-```
-
-Query all the rows.
-
-```sql
-cqlsh> SELECT email, profile FROM users.profile;
-```
-
-```
- email | profile
-------------------------------+---------------------------------------------------------------
- james.bond@yugabyte.com | {'firstname': 'James', 'lastname': 'Bond', 'nickname': '007'}
- sherlock.holmes@yugabyte.com | {'firstname': 'Sherlock', 'lastname': 'Holmes'}
-
-(2 rows)
-```
-
-
-## Step 3. Read data through another node
-
-Let us now query the data from node 5.
-
-```sh
-$ ./bin/cqlsh 127.0.0.5
-```
-
-```sql
-cqlsh> SELECT email, profile FROM users.profile;
-```
-
-```
- email | profile
-------------------------------+---------------------------------------------------------------
- james.bond@yugabyte.com | {'firstname': 'James', 'lastname': 'Bond', 'nickname': '007'}
- sherlock.holmes@yugabyte.com | {'firstname': 'Sherlock', 'lastname': 'Holmes'}
-
-(2 rows)
-```
-
-## 4. Verify that one node failure has no impact
-
-We have 5 nodes in this universe. You can verify this by running the following.
-
-```sh
-$ ./bin/yb-ctl status
-```
-
-```
-...
-2017-11-19 23:20:35,029 INFO: Server is running: type=tserver, node_id=1, ...
-2017-11-19 23:20:35,061 INFO: Server is running: type=tserver, node_id=2, ...
-2017-11-19 23:20:35,094 INFO: Server is running: type=tserver, node_id=3, ...
-2017-11-19 23:20:35,128 INFO: Server is running: type=tserver, node_id=4, ...
-2017-11-19 23:20:35,155 INFO: Server is running: type=tserver, node_id=5, ...
-```
-
-Let us simulate a node failure by removing node 5.
-
-```sh
-$ ./bin/yb-ctl remove_node 5
-```
-
-Now running the status command should show only 4 nodes:
-
-```sh
-$ ./bin/yb-ctl status
-```
-
-```
-...
-2017-11-19 23:20:35,029 INFO: Server is running: type=tserver, node_id=1, ...
-2017-11-19 23:20:35,061 INFO: Server is running: type=tserver, node_id=2, ...
-2017-11-19 23:20:35,094 INFO: Server is running: type=tserver, node_id=3, ...
-2017-11-19 23:20:35,128 INFO: Server is running: type=tserver, node_id=4, ...
-2017-11-19 23:22:12,997 INFO: Server type=tserver node_id=5 is not running
-```
-
-Now connect to node 4.
-
-```sh
-$ ./bin/cqlsh 127.0.0.4
-```
-
-Let us insert some data.
-
-```sql
-cqlsh> INSERT INTO users.profile (id, email, password, profile) VALUES
- (3000, 'austin.powers@yugabyte.com', 'imGroovy',
- {'firstname': 'Austin', 'lastname': 'Powers'});
-```
-
-Now query the data.
-
-```sql
-cqlsh> SELECT email, profile FROM users.profile;
-```
-
-```
- email | profile
-------------------------------+---------------------------------------------------------------
- james.bond@yugabyte.com | {'firstname': 'James', 'lastname': 'Bond', 'nickname': '007'}
- sherlock.holmes@yugabyte.com | {'firstname': 'Sherlock', 'lastname': 'Holmes'}
- austin.powers@yugabyte.com | {'firstname': 'Austin', 'lastname': 'Powers'}
-
-(3 rows)
-```
-
-
-## 5. Verify that second node failure has no impact
-
-This cluster was created with replication factor 5 and hence needs only 3 replicas to make consensus. Therefore, it is resilient to 2 failures without any data loss. Let us simulate another node failure.
-
-```sh
-$ ./bin/yb-ctl remove_node 1
-```
-
-We can check the status to verify:
-
-```sh
-$ ./bin/yb-ctl status
-```
-
-```
-...
-2017-11-19 23:31:02,183 INFO: Server type=tserver node_id=1 is not running
-2017-11-19 23:31:02,217 INFO: Server is running: type=tserver, node_id=2, ...
-2017-11-19 23:31:02,245 INFO: Server is running: type=tserver, node_id=3, ...
-2017-11-19 23:31:02,278 INFO: Server is running: type=tserver, node_id=4, ...
-2017-11-19 23:31:02,308 INFO: Server type=tserver node_id=5 is not running
-```
-
-Now let us connect to node 2.
-
-```sh
-$ ./bin/cqlsh 127.0.0.2
-```
-
-Insert some data.
-
-```sql
-cqlsh> INSERT INTO users.profile (id, email, password, profile) VALUES
- (4000, 'superman@yugabyte.com', 'iCanFly',
- {'firstname': 'Clark', 'lastname': 'Kent'});
-```
-
-Run the query.
-
-```sql
-cqlsh> SELECT email, profile FROM users.profile;
-```
-
-```
- email | profile
-------------------------------+---------------------------------------------------------------
- superman@yugabyte.com | {'firstname': 'Clark', 'lastname': 'Kent'}
- james.bond@yugabyte.com | {'firstname': 'James', 'lastname': 'Bond', 'nickname': '007'}
- sherlock.holmes@yugabyte.com | {'firstname': 'Sherlock', 'lastname': 'Holmes'}
- austin.powers@yugabyte.com | {'firstname': 'Austin', 'lastname': 'Powers'}
-
-(4 rows)
-```
-
-
-## 6. Clean up (optional)
-
-Optionally, you can shutdown the local cluster created in Step 1.
-
-```sh
-$ ./bin/yb-ctl destroy
-```
diff --git a/docs/content/latest/explore/cloud-native/binary/linear-scalability.md b/docs/content/latest/explore/cloud-native/binary/linear-scalability.md
deleted file mode 100644
index 7df15323b7c..00000000000
--- a/docs/content/latest/explore/cloud-native/binary/linear-scalability.md
+++ /dev/null
@@ -1,78 +0,0 @@
-## 1. Setup - create universe
-
-If you have a previously running local universe, destroy it using the following.
-
-```sh
-$ ./bin/yb-ctl destroy
-```
-
-Start a new local cluster - by default, this will create a 3-node universe with a replication factor of 3. We configure the number of [shards](../../../architecture/concepts/sharding/)(aka tablets) per table per tserver to 4 so that we can better observe the load balancing during scale-up and scale-down. Each table will now have 4 tablet-leaders in each tserver and with replication factor 3, there will be 2 tablet-followers for each tablet-leader distributed in the 2 other tservers. So each tserver will have 12 tablets (i.e. sum of 4 tablet-leaders and 8 tablet-followers) per table.
-
-```sh
-$ ./bin/yb-ctl --num_shards_per_tserver 4 create
-```
-
-## 2. Run sample key-value app
-
-Run the Cassandra sample key-value app against the local universe by typing the following command.
-
-```sh
-$ java -jar ./java/yb-sample-apps.jar --workload CassandraKeyValue \
- --nodes 127.0.0.1:9042 \
- --num_threads_write 1 \
- --num_threads_read 4 \
- --value_size 4096
-```
-
-The sample application prints some stats while running, which is also shown below. You can read more details about the output of the sample applications [here](../../../quick-start/run-sample-apps/).
-
-```
-2018-05-10 09:10:19,538 [INFO|...] Read: 8988.22 ops/sec (0.44 ms/op), 818159 total ops | Write: 1095.77 ops/sec (0.91 ms/op), 97120 total ops | ...
-2018-05-10 09:10:24,539 [INFO|...] Read: 9110.92 ops/sec (0.44 ms/op), 863720 total ops | Write: 1034.06 ops/sec (0.97 ms/op), 102291 total ops | ...
-```
-
-## 3. Observe IOPS per node
-
-You can check a lot of the per-node stats by browsing to the tablet-servers page. It should look like this. The total read and write IOPS per node are highlighted in the screenshot below. Note that both the reads and the writes are roughly the same across all the nodes indicating uniform usage across the nodes.
-
-
-
-## 4. Add node and observe linear scale out
-
-Add a node to the universe.
-
-```sh
-$ ./bin/yb-ctl --num_shards_per_tserver 4 add_node
-```
-
-Now we should have 4 nodes. Refresh the tablet-servers page to see the stats update. In a short time, you should see the new node performing a comparable number of reads and writes as the other nodes. The 36 tablets will now get distributed evenly across all the 4 nodes, leading to each node having 9 tablets.
-
-The YugaByte DB universe automatically let the client know to use the newly added node for serving queries. This scaling out of client queries is completely transparent to the application logic, allowing the application to scale linearly for both reads and writes.
-
-
-
-
-
-## 5. Remove node and observe linear scale in
-
-Remove the recently added node from the universe.
-
-```sh
-$ ./bin/yb-ctl remove_node 4
-```
-
-- Refresh the tablet-servers page to see the stats update. The `Time since heartbeat` value for that node will keep increasing. Once that number reaches 60s (i.e. 1 minute), YugaByte DB will change the status of that node from ALIVE to DEAD. Note that at this time the universe is running in an under-replicated state for some subset of tablets.
-
-
-
-- After 300s (i.e. 5 minutes), YugaByte DB's remaining nodes will re-spawn new tablets that were lost with the loss of node 4. Each remaining node's tablet count will increase from 9 to 12, thus getting back to the original state of 36 total tablets.
-
-
-
-## 6. Clean up (optional)
-
-Optionally, you can shutdown the local cluster created in Step 1.
-
-```sh
-$ ./bin/yb-ctl destroy
-```
diff --git a/docs/content/latest/explore/planet-scale/docker/auto-rebalancing.md b/docs/content/latest/explore/docker/auto-rebalancing.md
similarity index 100%
rename from docs/content/latest/explore/planet-scale/docker/auto-rebalancing.md
rename to docs/content/latest/explore/docker/auto-rebalancing.md
diff --git a/docs/content/latest/explore/planet-scale/docker/auto-sharding.md b/docs/content/latest/explore/docker/auto-sharding.md
similarity index 100%
rename from docs/content/latest/explore/planet-scale/docker/auto-sharding.md
rename to docs/content/latest/explore/docker/auto-sharding.md
diff --git a/docs/content/latest/explore/cloud-native/docker/fault-tolerance.md b/docs/content/latest/explore/docker/fault-tolerance.md
similarity index 100%
rename from docs/content/latest/explore/cloud-native/docker/fault-tolerance.md
rename to docs/content/latest/explore/docker/fault-tolerance.md
diff --git a/docs/content/latest/explore/cloud-native/docker/linear-scalability.md b/docs/content/latest/explore/docker/linear-scalability.md
similarity index 100%
rename from docs/content/latest/explore/cloud-native/docker/linear-scalability.md
rename to docs/content/latest/explore/docker/linear-scalability.md
diff --git a/docs/content/latest/explore/cloud-native/docker/observability.md b/docs/content/latest/explore/docker/observability.md
similarity index 100%
rename from docs/content/latest/explore/cloud-native/docker/observability.md
rename to docs/content/latest/explore/docker/observability.md
diff --git a/docs/content/latest/explore/high-performance/docker/tunable-reads.md b/docs/content/latest/explore/docker/tunable-reads.md
similarity index 100%
rename from docs/content/latest/explore/high-performance/docker/tunable-reads.md
rename to docs/content/latest/explore/docker/tunable-reads.md
diff --git a/docs/content/latest/explore/cloud-native/fault-tolerance.md b/docs/content/latest/explore/fault-tolerance.md
similarity index 76%
rename from docs/content/latest/explore/cloud-native/fault-tolerance.md
rename to docs/content/latest/explore/fault-tolerance.md
index a70325b0709..0da277d1547 100644
--- a/docs/content/latest/explore/cloud-native/fault-tolerance.md
+++ b/docs/content/latest/explore/fault-tolerance.md
@@ -5,17 +5,21 @@ description: Fault Tolerance
aliases:
- /explore/fault-tolerance/
- /latest/explore/fault-tolerance/
+ - /latest/explore/cloud-native/fault-tolerance/
+ - /latest/explore/postgresql/fault-tolerance/
menu:
latest:
identifier: fault-tolerance
- parent: explore-cloud-native
+ parent: explore
weight: 215
---
-YugaByte DB can automatically handle failures and therefore provides [high availability](../../../architecture/core-functions/high-availability/) for both Redis as well as Cassandra tables. In this tutorial, we will look at how fault tolerance is achieved for Cassandra, but the same steps would work for Redis tables as well. Except for the Kubernetes example, we will create these tables with a replication factor = 5 that allows a [fault tolerance](../../../architecture/concepts/replication/) of 2. We will then insert some data through one of the nodes, and query the data from another node. We will then simulate two node failures (one by one) and make sure we are able to successfully query and write data after each of these failures.
+YugaByte DB can automatically handle failures and therefore provides [high availability](../../../architecture/core-functions/high-availability/) for YSQL tables. We will create these tables with a replication factor = 3 that allows a [fault tolerance](../../../architecture/concepts/docdb/replication/) of 1. This means the cluster will remain available for both reads and writes even if one node fails. However, if another node fails bringing the number of failures to 2, then writes will become unavailable on the cluster in order to preserve data consistency.
+
If you haven't installed YugaByte DB yet, do so first by following the [Quick Start](../../../quick-start/install/) guide.
+
-
diff --git a/docs/content/latest/explore/planet-scale/global-distribution.md b/docs/content/latest/explore/global-distribution.md
similarity index 93%
rename from docs/content/latest/explore/planet-scale/global-distribution.md
rename to docs/content/latest/explore/global-distribution.md
index 9b0d4273296..1bf0eaf8289 100644
--- a/docs/content/latest/explore/planet-scale/global-distribution.md
+++ b/docs/content/latest/explore/global-distribution.md
@@ -1,15 +1,16 @@
---
title: Global Distribution
-linkTitle: 1. Global Distribution
+linkTitle: 3. Global Distribution
description: Global Distribution
aliases:
- /explore/global-distribution/
- /latest/explore/global-distribution/
+ - /latest/explore/planet-scale/global-distribution/
menu:
latest:
identifier: global-distribution
- parent: explore-planet-scale
- weight: 260
+ parent: explore
+ weight: 220
---
YugaByte DB can easily be deployed in a globally distributed manner to serve application queries from the region closest to the end users with low latencies as well as to survive any outages to ensure high availability.
diff --git a/docs/content/latest/explore/high-performance/_index.md b/docs/content/latest/explore/high-performance/_index.md
deleted file mode 100644
index 741ba0d7407..00000000000
--- a/docs/content/latest/explore/high-performance/_index.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Explore High Performance Features
-linkTitle: High Performance
-description: High Performance
-headcontent:
-image: /images/section_icons/explore/high_performance.png
-aliases:
- - /explore/high-performance/
-menu:
- latest:
- identifier: explore-high-perf
- parent: explore
- weight: 240
----
-
-
\ No newline at end of file
diff --git a/docs/content/latest/explore/planet-scale/kubernetes/auto-rebalancing.md b/docs/content/latest/explore/kubernetes/auto-rebalancing.md
similarity index 100%
rename from docs/content/latest/explore/planet-scale/kubernetes/auto-rebalancing.md
rename to docs/content/latest/explore/kubernetes/auto-rebalancing.md
diff --git a/docs/content/latest/explore/planet-scale/kubernetes/auto-sharding.md b/docs/content/latest/explore/kubernetes/auto-sharding.md
similarity index 100%
rename from docs/content/latest/explore/planet-scale/kubernetes/auto-sharding.md
rename to docs/content/latest/explore/kubernetes/auto-sharding.md
diff --git a/docs/content/latest/explore/cloud-native/kubernetes/fault-tolerance.md b/docs/content/latest/explore/kubernetes/fault-tolerance.md
similarity index 100%
rename from docs/content/latest/explore/cloud-native/kubernetes/fault-tolerance.md
rename to docs/content/latest/explore/kubernetes/fault-tolerance.md
diff --git a/docs/content/latest/explore/cloud-native/kubernetes/linear-scalability.md b/docs/content/latest/explore/kubernetes/linear-scalability.md
similarity index 100%
rename from docs/content/latest/explore/cloud-native/kubernetes/linear-scalability.md
rename to docs/content/latest/explore/kubernetes/linear-scalability.md
diff --git a/docs/content/latest/explore/cloud-native/kubernetes/observability.md b/docs/content/latest/explore/kubernetes/observability.md
similarity index 100%
rename from docs/content/latest/explore/cloud-native/kubernetes/observability.md
rename to docs/content/latest/explore/kubernetes/observability.md
diff --git a/docs/content/latest/explore/high-performance/kubernetes/tunable-reads.md b/docs/content/latest/explore/kubernetes/tunable-reads.md
similarity index 100%
rename from docs/content/latest/explore/high-performance/kubernetes/tunable-reads.md
rename to docs/content/latest/explore/kubernetes/tunable-reads.md
diff --git a/docs/content/latest/explore/cloud-native/linear-scalability.md b/docs/content/latest/explore/linear-scalability.md
similarity index 95%
rename from docs/content/latest/explore/cloud-native/linear-scalability.md
rename to docs/content/latest/explore/linear-scalability.md
index 463781bce53..ddc0fcea04b 100644
--- a/docs/content/latest/explore/cloud-native/linear-scalability.md
+++ b/docs/content/latest/explore/linear-scalability.md
@@ -5,10 +5,12 @@ description: Linear Scalability
aliases:
- /explore/linear-scalability/
- /latest/explore/linear-scalability/
+ - /latest/explore/cloud-native/linear-scalability/
+ - /latest/explore/postgresql/linear-scalability/
menu:
latest:
identifier: linear-scalability
- parent: explore-cloud-native
+ parent: explore
weight: 210
---
diff --git a/docs/content/latest/explore/cloud-native/observability.md b/docs/content/latest/explore/observability.md
similarity index 94%
rename from docs/content/latest/explore/cloud-native/observability.md
rename to docs/content/latest/explore/observability.md
index fea89cd3f28..17e3e7e38fe 100644
--- a/docs/content/latest/explore/cloud-native/observability.md
+++ b/docs/content/latest/explore/observability.md
@@ -1,12 +1,14 @@
---
title: Observability with Prometheus
-linkTitle: 3. Observability
+linkTitle: 7. Observability
description: Observability with Prometheus
+aliases:
+ - /latest/explore/cloud-native/observability/
menu:
latest:
identifier: observability
- parent: explore-cloud-native
- weight: 216
+ parent: explore
+ weight: 240
---
You can monitor your local YugaByte DB cluster with a local instance of [Prometheus](https://prometheus.io/), the de-facto standard for time-series monitoring of cloud native infrastructure. Every YugaByte DB service exposes metrics in the Prometheus format at the `/prometheus-metrics` endpoint.
diff --git a/docs/content/latest/explore/cloud-native/orchestration-readiness.md b/docs/content/latest/explore/orchestration-readiness.md
similarity index 91%
rename from docs/content/latest/explore/cloud-native/orchestration-readiness.md
rename to docs/content/latest/explore/orchestration-readiness.md
index 5ece56f09bc..febf6b4c29a 100644
--- a/docs/content/latest/explore/cloud-native/orchestration-readiness.md
+++ b/docs/content/latest/explore/orchestration-readiness.md
@@ -1,12 +1,14 @@
---
title: Orchestration Readiness
-linkTitle: 4. Orchestration Readiness
+linkTitle: 8. Orchestration Readiness
description: Orchestration Readiness
+aliases:
+ - /latest/explore/cloud-native/orchestration-readiness/
menu:
latest:
identifier: orchestration-readiness
- parent: explore-cloud-native
- weight: 217
+ parent: explore
+ weight: 245
---
YugaByte DB is orchestration-ready on all major infrastructure layers including containers, virtual machines (VMs) and bare metal.
diff --git a/docs/content/latest/explore/planet-scale/_index.md b/docs/content/latest/explore/planet-scale/_index.md
deleted file mode 100644
index 65ac262545b..00000000000
--- a/docs/content/latest/explore/planet-scale/_index.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: Explore Planet-Scale Features
-linkTitle: Planet Scale
-description: Planet Scale
-headcontent:
-image: /images/section_icons/explore/planet_scale.png
-aliases:
- - /explore/planet-scale/
-menu:
- latest:
- identifier: explore-planet-scale
- parent: explore
- weight: 250
----
-
-
\ No newline at end of file
diff --git a/docs/content/latest/explore/postgresql/_index.md b/docs/content/latest/explore/postgresql/_index.md
deleted file mode 100644
index f97a829c576..00000000000
--- a/docs/content/latest/explore/postgresql/_index.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: Explore PostgreSQL Features
-linkTitle: PostgreSQL (Beta)
-description: PostgreSQL (Beta)
-headcontent:
-image: /images/section_icons/api/pgsql.png
-beta: /faq/product/#what-is-the-definition-of-the-beta-feature-tag
-menu:
- latest:
- identifier: explore-pgsql
- parent: explore
- weight: 290
----
-
-This section highlights the core features of YugaByte DB's PostgreSQL-compatible YSQL API.
-
-
-
-
\ No newline at end of file
diff --git a/docs/content/latest/explore/postgresql/aggregations.md b/docs/content/latest/explore/postgresql/aggregations.md
deleted file mode 100644
index c02222351f8..00000000000
--- a/docs/content/latest/explore/postgresql/aggregations.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: Aggregations
-linkTitle: 4. Aggregations
-description: Aggregations
-menu:
- latest:
- identifier: pgsql-agg
- parent: explore-pgsql
- weight: 294
----
-
-Aggregates functions are supported. However, the computation of these aggregations is not yet pushed down to the individual nodes. This is a performance optimization that we expect to be available in future beta releases.
-
-If you haven't installed YugaByte DB yet, do so first by following the [Quick Start](../../../quick-start/install/) guide.
-
-
-
-
-
- {{% includeMarkdown "binary/aggregations.md" /%}}
-
-
- {{% includeMarkdown "binary/aggregations.md" /%}}
-
-
- {{% includeMarkdown "docker/aggregations.md" /%}}
-
-
-
- {{% includeMarkdown "binary/expressions.md" /%}}
-
-
- {{% includeMarkdown "binary/expressions.md" /%}}
-
-
- {{% includeMarkdown "docker/expressions.md" /%}}
-
-
-
- {{% includeMarkdown "binary/fault-tolerance.md" /%}}
-
-
- {{% includeMarkdown "binary/fault-tolerance.md" /%}}
-
-
-
-
- {{% includeMarkdown "binary/joins.md" /%}}
-
-
- {{% includeMarkdown "binary/joins.md" /%}}
-
-
- {{% includeMarkdown "docker/joins.md" /%}}
-
-
-
- {{% includeMarkdown "binary/linear-scalability.md" /%}}
-
-
- {{% includeMarkdown "binary/linear-scalability.md" /%}}
-
-
-
-
- {{% includeMarkdown "binary/views.md" /%}}
-
-
- {{% includeMarkdown "binary/views.md" /%}}
-
-
- {{% includeMarkdown "docker/views.md" /%}}
-
-
-
- {{% includeMarkdown "binary/transactions.md" /%}}
-
-
- {{% includeMarkdown "binary/transactions.md" /%}}
-
-
- {{% includeMarkdown "docker/transactions.md" /%}}
-
-
- {{% includeMarkdown "kubernetes/transactions.md" /%}}
-
-
-
- {{% includeMarkdown "binary/json-documents.md" /%}}
-
-
- {{% includeMarkdown "binary/json-documents.md" /%}}
-
-
- {{% includeMarkdown "docker/json-documents.md" /%}}
-
-
- {{% includeMarkdown "kubernetes/json-documents.md" /%}}
-
-
-
- {{% includeMarkdown "binary/secondary-indexes.md" /%}}
-
-
- {{% includeMarkdown "binary/secondary-indexes.md" /%}}
-
-
- {{% includeMarkdown "docker/secondary-indexes.md" /%}}
-
-
- {{% includeMarkdown "kubernetes/secondary-indexes.md" /%}}
-
-
diff --git a/docs/content/latest/faq/architecture.md b/docs/content/latest/faq/architecture.md
index f8ddfde3b0d..d140a62918f 100644
--- a/docs/content/latest/faq/architecture.md
+++ b/docs/content/latest/faq/architecture.md
@@ -8,7 +8,7 @@ menu:
latest:
identifier: faq-architecture
parent: faq
- weight: 2480
+ weight: 2720
isTocNested: false
showAsideToc: true
---
diff --git a/docs/content/latest/faq/cassandra.md b/docs/content/latest/faq/cassandra.md
index c31a0d7ef54..81a25af5939 100644
--- a/docs/content/latest/faq/cassandra.md
+++ b/docs/content/latest/faq/cassandra.md
@@ -8,7 +8,7 @@ menu:
latest:
identifier: cassandra-api
parent: faq
- weight: 2500
+ weight: 2740
isTocNested: false
showAsideToc: true
---
diff --git a/docs/content/latest/faq/enterprise-edition.md b/docs/content/latest/faq/enterprise-edition.md
index 33e01666d26..bb12fe7c373 100644
--- a/docs/content/latest/faq/enterprise-edition.md
+++ b/docs/content/latest/faq/enterprise-edition.md
@@ -8,7 +8,7 @@ menu:
latest:
identifier: enterprise-edition
parent: faq
- weight: 2490
+ weight: 2730
isTocNested: false
showAsideToc: true
---
diff --git a/docs/content/latest/faq/product.md b/docs/content/latest/faq/product.md
index 7df0942e203..a82b8568f6e 100644
--- a/docs/content/latest/faq/product.md
+++ b/docs/content/latest/faq/product.md
@@ -8,7 +8,7 @@ menu:
latest:
identifier: product
parent: faq
- weight: 2470
+ weight: 2710
isTocNested: false
showAsideToc: true
---
diff --git a/docs/content/latest/introduction.md b/docs/content/latest/introduction.md
index 61e488cb97c..8263e9efa27 100644
--- a/docs/content/latest/introduction.md
+++ b/docs/content/latest/introduction.md
@@ -22,9 +22,7 @@ showAsideToc: true
{{< vimeo 305074082 >}}
-YugaByte DB is a transactional, high-performance database for building internet-scale, globally-distributed applications. Built using a unique combination of distributed document store, auto sharding, per-shard distributed consensus replication and multi-shard ACID transactions (inspired by Google Spanner), it is world's only distributed database that is both non-relational (support for Redis-compatible KV & Cassandra-compatible flexible schema transactional NoSQL APIs) and relational (support for PostgreSQL-compatible distributed SQL API) at the same time.
-
-YugaByte DB is purpose-built to power fast-growing online services on public, private and hybrid clouds with transactional integrity, high availabilty, low latency, high throughput and multi-region scalability while also providing unparalleled data modeling freedom to application architects. Enterprises gain more functional depth and agility without any cloud lock-in when compared to proprietary cloud databases such as Amazon DynamoDB, Microsoft Azure Cosmos DB and Google Cloud Spanner. Enterprises also benefit from stronger data integrity guarantees, more reliable scaling and higher performance than those offered by legacy open source NoSQL databases such as MongoDB and Apache Cassandra.
+YugaByte DB is a high-performance SQL database for powering internet-scale, globally-distributed applications. Built using a unique combination of high-performance document store, auto sharding, per-shard distributed consensus replication and multi-shard ACID transactions (inspired by Google Spanner), YugaByte DB serves both scale-out RDBMS and internet-scale OLTP workloads with low query latency, extreme resilience against failures and global data distribution. As a cloud native database, it can be deployed across public and private clouds as well as in Kubernetes environments with ease.
YugaByte DB Community Edition is developed and distributed as an [Apache 2.0 open source project](https://github.com/YugaByte/yugabyte-db/).
@@ -40,11 +38,11 @@ YugaByte DB feature highlights are listed below.
- [Distributed acid transactions](../explore/transactional/) that allow multi-row updates across any number of shards at any scale.
-- Transactional [document store](../architecture/concepts/persistence/) backed by self-healing, strongly consistent [replication](../architecture/concepts/replication/).
+- Transactional [document store](../architecture/concepts/docdb/) backed by self-healing, strongly consistent [replication](../architecture/concepts/docdb/replication/).
### 2. High Performance
-- Low latency for geo-distributed applications with multiple [read consistency levels](../architecture/concepts/replication/#tunable-read-consistency) and [read-only replicas](../architecture/concepts/replication/#read-only-replicas).
+- Low latency for geo-distributed applications with multiple [read consistency levels](../architecture/concepts/docdb/replication/#tunable-read-consistency) and [read-only replicas](../architecture/concepts/docdb/replication/#read-only-replicas).
- High throughput for ingesting and serving ever-growing datasets.
@@ -64,38 +62,23 @@ YugaByte DB feature highlights are listed below.
- Fully functional distributed database available under [Apache 2.0 open source license](https://github.com/YugaByte/yugabyte-db/). Upgrade to [Enterprise Edition](https://www.yugabyte.com/product/compare/) anytime.
-- Multi-API/multi-model database that extends existing popular and open APIs including Cassandra, Redis and PostgreSQL.
-
## What client APIs are supported by YugaByte DB?
-YugaByte DB supports both Transactional NoSQL and Distributed SQL APIs.
-
-1. [YEDIS](../api/yedis/) - YEDIS is a transactional key-value API that is wire compatible with [Redis](https://redis.io/commands) commands library and client drivers. YEDIS extends Redis with a new native [Time Series](https://blog.yugabyte.com/extending-redis-with-a-native-time-series-data-type-e5483c7116f8) data type.
+YugaByte DB supports two flavors of distributed SQL.
-2. [YCQL](../api/ycql/) - YCQL is a transactional flexible-schema API that is wire compatible with [Apache Cassandra Query Language (CQL)](https://docs.datastax.com/en/cql/3.1/cql/cql_reference/cqlReferenceTOC.html) and its client drivers. YCQL extends CQL by adding [distributed ACID transactions](../explore/transactional/acid-transactions/), [strongly consistent secondary indexes](../explore/transactional/secondary-indexes/) and a [native JSON column type](../explore/transactional/json-documents/).
-
-3. [YSQL (Beta)](../api/ysql/) - YSQL is a distributed SQL API that is wire compatible with the SQL language in [PostgreSQL](https://www.postgresql.org/docs/10/sql-syntax.html).
+1. [YugaByte SQL (Beta)](../api/ysql/) - YSQL is a fully relational SQL API that is wire compatible with the SQL language in PostgreSQL. It is best fit for RDBMS workloads that need horizontal scalability and global distribution while also using relational data modeling features such as JOINs, referential integrity, and multi-table transactions.
+2. [YugaByte Cloud QL](../api/ycql/) - YCQL is a SQL-based flexible-schema API that is best fit for internet-scale OLTP apps needing a semi-relational API highly optimized for write-intensive applications as well as blazing-fast queries. It supports [distributed ACID transactions](../explore/transactional/acid-transactions/), [strongly consistent secondary indexes](../explore/transactional/secondary-indexes/) and a [native JSON column type](../explore/transactional/json-documents/). YCQL has its roots in the Cassandra Query Language.
{{< note title="Note" >}}
-The three YugaByte DB APIs are completely isolated and independent from one another. This means that the data inserted or managed by one API cannot be queried by a different API. Additionally, there is no common way to access the data across all the APIs (external frameworks such as [Presto](../develop/ecosystem-integrations/presto/) can help for simple cases).
+The YugaByte DB APIs are completely isolated and independent from one another today. This means that the data inserted or managed by one API cannot be queried by th other API. Additionally, there is no common way to access the data across the APIs (external frameworks such as [Presto](../develop/ecosystem-integrations/presto/) can help for simple cases).
The net impact is that application developers have to select an API first before undertaking detailed database schema/query design and implementation.
{{< /note >}}
-## Which API should I select for my application?
-
-**For internet-scale transactional workloads, the question of which API to select is a trade-off between data modeling richness and query performance.**
-
-- On one end of the spectrum is the [YEDIS](../api/yedis/) API that is completely optimized for single key access patterns, has simpler data modeling constructs and provides blazing-fast (sub-ms) query performance.
-
-- On the other end of the spectrum is the [YSQL](../api/ysql/) API that supports complex multi-key relationships (through JOINS and foreign keys) and provides normal (single-digit ms) query performance. This is expected since multiple keys can be located on multiple shards hosted on multiple nodes, resulting in higher latency than a key-value API that accesses only a single key at any time.
-
-- At the middle of the spectrum is the [YCQL](../api/ycql/) API that is still optimized for majority single-key workloads but has richer data modeling features such as globally consistent secondary indexes (powered by distributed ACID transactions) that can accelerate internet-scale application development significantly.
-
## How does YugaByte DB's common document store work?
-[DocDB](../architecture/concepts/persistence/), YugaByte DB's distributed document store common across all APIs, builds on top of the popular RocksDB project by transforming RocksDB from a key-value store (with only primitive data types) to a document store (with complex data types). **Every key is stored as a separate document in DocDB, irrespective of the API responsible for managing the key.** DocDB’s [sharding](../architecture/concepts/sharding/), [replication/fault-tolerance](../architecture/concepts/replication/) and [distributed ACID transactions](../architecture/transactions/distributed-txns/) architecture are all based on the the [Google Spanner design](https://research.google.com/archive/spanner-osdi2012.pdf) first published in 2012.
+[DocDB](../architecture/concepts/docdb/), YugaByte DB's distributed document store common across all APIs, builds on top of the popular RocksDB project by transforming RocksDB from a key-value store (with only primitive data types) to a document store (with complex data types). **Every key is stored as a separate document in DocDB, irrespective of the API responsible for managing the key.** DocDB’s [sharding](../architecture/concepts/docdb/sharding/), [replication/fault-tolerance](../architecture/concepts/docdb/replication/) and [distributed ACID transactions](../architecture/transactions/distributed-txns/) architecture are all based on the the [Google Spanner design](https://research.google.com/archive/spanner-osdi2012.pdf) first published in 2012. [How We Built a High Performance Document Store on RocksDB?](https://blog.yugabyte.com/how-we-built-a-high-performance-document-store-on-rocksdb/) provides an in-depth look into DocDB.
diff --git a/docs/content/latest/manage/backup-restore/backing-up-data.md b/docs/content/latest/manage/backup-restore/backing-up-data.md
index a0d0dcea7b7..101ccc54fe5 100644
--- a/docs/content/latest/manage/backup-restore/backing-up-data.md
+++ b/docs/content/latest/manage/backup-restore/backing-up-data.md
@@ -31,14 +31,14 @@ Dump the keyspace schema (optional) as well as the data in the tables to create
-
- Cassandra
+ YCQL
- {{% includeMarkdown "cassandra/backing-up-data.md" /%}}
+ {{% includeMarkdown "ycql/backing-up-data.md" /%}}
diff --git a/docs/content/latest/manage/backup-restore/restoring-data.md b/docs/content/latest/manage/backup-restore/restoring-data.md
index 2ff73dd04a2..a288c7785fe 100644
--- a/docs/content/latest/manage/backup-restore/restoring-data.md
+++ b/docs/content/latest/manage/backup-restore/restoring-data.md
@@ -19,14 +19,14 @@ This page covers how to restore data from a backup. In order to create a backup,
- Cassandra
+ YCQL
- {{% includeMarkdown "cassandra/restoring-data.md" /%}}
+ {{% includeMarkdown "ycql/restoring-data.md" /%}}
diff --git a/docs/content/latest/manage/backup-restore/cassandra/backing-up-data.md b/docs/content/latest/manage/backup-restore/ycql/backing-up-data.md
similarity index 100%
rename from docs/content/latest/manage/backup-restore/cassandra/backing-up-data.md
rename to docs/content/latest/manage/backup-restore/ycql/backing-up-data.md
diff --git a/docs/content/latest/manage/backup-restore/cassandra/restoring-data.md b/docs/content/latest/manage/backup-restore/ycql/restoring-data.md
similarity index 100%
rename from docs/content/latest/manage/backup-restore/cassandra/restoring-data.md
rename to docs/content/latest/manage/backup-restore/ycql/restoring-data.md
diff --git a/docs/content/latest/quick-start/_index.md b/docs/content/latest/quick-start/_index.md
index ae7fd91d2ce..67545223b82 100644
--- a/docs/content/latest/quick-start/_index.md
+++ b/docs/content/latest/quick-start/_index.md
@@ -46,38 +46,14 @@ We do not recommend a local multi-node cluster setup on a single host for produc
@@ -86,7 +62,7 @@ We do not recommend a local multi-node cluster setup on a single host for produc
+ 
- 
- 
+ 
- 
- 
+ 
+ 
+
+ 
+ 
- 
+ 
- 
+ 
+ 
+ 
+ 
+ 
- 
- 
- 
- 
- 
- 
- 
- 
- 
+ 
+ 
+