{{% includeMarkdown "./tablespaces-yugabyted.md" %}}
{{% includeMarkdown "./tablespaces-platform.md" %}}
## Create a single-zone table
By default, creating any tables in the preceding cluster spreads all of its data across all regions. Using tablespaces, you can constrain table data in a single zone. The placement policy is illustrated using the following diagram:
Create a tablespace outlining the preceding placement policy and a table associated with that tablespace:
```sql
CREATE TABLESPACE us_east_1a_zone_tablespace
WITH (replica_placement='{"num_replicas": 3, "placement_blocks": [
{"cloud":"aws","region":"us-east-1","zone":"us-east-1a","min_num_replicas":3}]}');
CREATE TABLE single_zone_table (id INTEGER, field text)
TABLESPACE us_east_1a_zone_tablespace SPLIT INTO 1 TABLETS;
```
To view your tablespaces, you can enter the following command:
```sql
SELECT * FROM pg_tablespace;
```
Note from the preceding cluster configuration that the nodes in us-east-1a were 172.152.29.181, 172.152.27.126, and 172.152.22.180. By navigating to the table view in the YB-Master UI, you can verify that the tablet created for this table was indeed placed in us_east_1a_zone:
To measure the latencies incurred for INSERTs and SELECTs on this table, where the client is in us-east-1a zone, enter the following command:
```sql
yugabyte=# INSERT INTO single_zone_table VALUES (1, 'field1'), (2, 'field2'), (3, 'field3');
```
```output
Time: 4.676 ms
```
```sql
yugabyte=# SELECT * FROM single_zone_table;
```
```output
id | field
----+--------
2 | field2
1 | field1
3 | field3
(3 rows)
Time: 1.880 ms
```
## Create a multi-zone table
The following diagram is a graphical representation of a table that is spread across multiple zones in the same region:
```sql
CREATE TABLESPACE us_east_region_tablespace
WITH (replica_placement='{"num_replicas": 3, "placement_blocks": [
{"cloud":"aws","region":"us-east-1","zone":"us-east-1a","min_num_replicas":1},
{"cloud":"aws","region":"us-east-1","zone":"us-east-1b","min_num_replicas":1},
{"cloud":"aws","region":"us-east-1","zone":"us-east-1c","min_num_replicas":1}]}');
CREATE TABLE multi_zone_table (id INTEGER, field text)
TABLESPACE us_east_region_tablespace SPLIT INTO 1 TABLETS;
```
The following demonstrates how to measure the latencies incurred for INSERTs and SELECTs on this table, where the client is in us-east-1a zone:
```sql
yugabyte=# INSERT INTO multi_zone_table VALUES (1, 'field1'), (2, 'field2'), (3, 'field3');
```
```output
Time: 11.825 ms
```
```sql
yugabyte=# SELECT * FROM multi_zone_table;
```
```output
id | field
----+--------
1 | field1
3 | field3
2 | field2
(3 rows)
Time: 4.145 ms
```
## Create a multi-region table
The following diagram is a graphical representation of a table spread across multiple regions:
```sql
CREATE TABLESPACE multi_region_tablespace
WITH (replica_placement='{"num_replicas": 3, "placement_blocks": [
{"cloud":"aws","region":"us-east-1","zone":"us-east-1b","min_num_replicas":1},
{"cloud":"aws","region":"ap-south-1","zone":"ap-south-1a","min_num_replicas":1},
{"cloud":"aws","region":"eu-west-2","zone":"eu-west-2c","min_num_replicas":1}]}');
CREATE TABLE multi_region_table (id INTEGER, field text)
TABLESPACE multi_region_tablespace SPLIT INTO 1 TABLETS;
```
The following demonstrates how to measure the latencies incurred for INSERTs and SELECTs on this table, where the client is in us-east-1a zone:
```sql
yugabyte=# INSERT INTO multi_region_table VALUES (1, 'field1'), (2, 'field2'), (3, 'field3');
```
```output
Time: 863.616 ms
```
```sql
yugabyte=# SELECT * FROM multi_region_table;
```
```output
id | field
----+--------
3 | field3
2 | field2
1 | field1
(3 rows)
Time: 337.154 ms
```
### Use wildcards for zones
Sometimes, you may want to use the wildcard `*` in the placement block list. This is handy when the number of zones is greater than the replication factor (RF) of your cluster. In these cases, you can use the wildcard to randomly choose any of the zones in a given region, or any of the regions in a given cloud.
For example, assume a cluster is spread out over regions `us-east-1` (AZs `us-east-1a`, `us-east-1b`), `us-central-1` (AZs `us-central-1a`, `us-central-1b`) and `us-west-1` (AZs `us-west-1a`, `us-west-1b`) and you want to create an RF3 tablespace.
The tablespace in the following example allows copies to be placed in each of the three regions without specifying the exact AZs in those regions. This can increase the resilience of the cluster compared to explicitly specifying exactly one AZ per region. However, note that when using wildcard placement mode, each AZ in the region must be over-provisioned appropriately to handle the tablets that it may receive from the other AZ's failover.
```sql
CREATE TABLESPACE multi_region_wildcard_tablespace
WITH (replica_placement='{"num_replicas": 3, "placement_blocks": [
{"cloud":"aws","region":"us-east-1","zone":"*","min_num_replicas":1},
{"cloud":"aws","region":"us-west-1","zone":"*","min_num_replicas":1},
{"cloud":"aws","region":"us-central-1","zone":"*","min_num_replicas":1}]}');
CREATE TABLE multi_region_table (id INTEGER, field text)
TABLESPACE multi_region_wildcard_tablespace;
```
Similarly, the following tablespace allows copies to be placed in any zone and region in the `aws` cloud.
```sql
CREATE TABLESPACE aws_wildcard_tablespace
WITH (replica_placement='{"num_replicas": 3, "placement_blocks": [
{"cloud":"aws","region":"*","zone":"*","min_num_replicas":3}]}');
CREATE TABLE aws_wildcard_table (id INTEGER, field text)
TABLESPACE aws_wildcard_tablespace;
```
{{< note title="Tablet distribution" >}}
There is no guarantee that tablets are uniformly distributed over independent AZs in this case. Comment on issue {{
Local
YugabyteDB Anywhere