The ALTER DATABASE [statement]({% link {{ page.version.version }}/sql-statements.md %}) applies a [schema change]({% link {{ page.version.version }}/online-schema-changes.md %}) to a database.

{{site.data.alerts.callout_info}} {% include {{ page.version.version }}/misc/schema-change-view-job.md %} {{site.data.alerts.end}}

Refer to the respective subcommands.

Additional parameters are documented for the respective subcommands.

ALTER DATABASE .. ADD REGION adds a [region]({% link {{ page.version.version }}/multiregion-overview.md %}#database-regions) to a [multi-region database]({% link {{ page.version.version }}/multiregion-overview.md %}). While CockroachDB processes an index modification or changing a table to or from a [REGIONAL BY ROW table]({% link {{ page.version.version }}/table-localities.md %}#regional-by-row-tables), attempting to drop a region from the database containing that REGIONAL BY ROW table will produce an error. Similarly, while this statement is running, all index modifications and locality changes on [REGIONAL BY ROW]({% link {{ page.version.version }}/table-localities.md %}#regional-by-row-tables) tables will be blocked.

{{site.data.alerts.callout_danger}} In order to add a region with ADD REGION, you must first set a primary database region with SET PRIMARY REGION, or at [database creation]({% link {{ page.version.version }}/create-database.md %}). For an example showing how to add a primary region with ALTER DATABASE, see Set the primary region. {{site.data.alerts.end}}

For examples, see Manage regions.

To add a region to a database, the user must have one of the following:

• Membership to the [admin]({% link {{ page.version.version }}/security-reference/authorization.md %}#admin-role) role for the cluster.
• Either [ownership]({% link {{ page.version.version }}/security-reference/authorization.md %}#object-ownership) or the [CREATE privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges) for the database and all [REGIONAL BY ROW]({% link {{ page.version.version }}/table-localities.md %}#regional-by-row-tables) tables in the database.

For usage, see Synopsis.

ALTER DATABASE .. ADD SUPER REGION adds a [super region]({% link {{ page.version.version }}/multiregion-overview.md %}#super-regions) to a [multi-region database]({% link {{ page.version.version }}/multiregion-overview.md %}).

{{site.data.alerts.callout_info}} {% include feature-phases/preview.md %} {{site.data.alerts.end}}

{% include {{page.version.version}}/sql/super-region-considerations.md %}

For examples, see Manage super regions.

To add a super region to a database, the user must have one of the following:

• Membership to the [admin]({% link {{ page.version.version }}/security-reference/authorization.md %}#admin-role) role for the cluster.
• Either [ownership]({% link {{ page.version.version }}/security-reference/authorization.md %}#object-ownership) or the [CREATE privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges) for the database.

For usage, see Synopsis.

ALTER DATABASE .. ALTER LOCALITY provides a customization tool for advanced users to persistently modify the configuration generated by the standard [multi-region SQL abstractions]({% link {{ page.version.version }}/multiregion-overview.md %}) on a per-region basis.

The feature this statement enables is also known as Zone Config Extensions. For more information about how it works, and the benefits over using the low-level CONFIGURE ZONE statement, see [Zone Config Extensions]({% link {{ page.version.version }}/zone-config-extensions.md %}).

For examples, see Use Zone Config Extensions.

The user must be a member of the [admin]({% link {{ page.version.version }}/security-reference/authorization.md %}#roles) or [owner]({% link {{ page.version.version }}/security-reference/authorization.md %}#object-ownership) roles, or have the [CREATE privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges) on the database.

For usage, see Synopsis.

ALTER DATABASE .. ALTER SUPER REGION alters an existing [super region]({% link {{ page.version.version }}/multiregion-overview.md %}#super-regions) of a [multi-region database]({% link {{ page.version.version }}/multiregion-overview.md %}).

{{site.data.alerts.callout_info}} {% include feature-phases/preview.md %} {{site.data.alerts.end}}

{% include {{page.version.version}}/sql/super-region-considerations.md %}

For examples, see Manage super regions.

To alter a database's super region, the user must have one of the following:

• Membership to the [admin]({% link {{ page.version.version }}/security-reference/authorization.md %}#admin-role) role for the cluster.
• Either [ownership]({% link {{ page.version.version }}/security-reference/authorization.md %}#object-ownership) or the [CREATE privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges) for the database.

For usage, see Synopsis.

ALTER DATABASE ... CONFIGURE ZONE is used to add, modify, reset, or remove replication zones for a database. To view details about existing replication zones, use [SHOW ZONE CONFIGURATIONS]({% link {{ page.version.version }}/show-zone-configurations.md %}). For more information about replication zones, see [Replication Controls]({% link {{ page.version.version }}/configure-replication-zones.md %}).

{{site.data.alerts.callout_danger}} If you directly change a database's zone configuration with ALTER DATABASE ... CONFIGURE ZONE, CockroachDB will block all ALTER DATABASE ... SET PRIMARY REGION statements on the database. {{site.data.alerts.end}}

You can use replication zones to control the number and location of replicas for specific sets of data, both when replicas are first added and when they are rebalanced to maintain cluster equilibrium.

For examples, see Replication Controls.

The user must be a member of the [admin role]({% link {{ page.version.version }}/security-reference/authorization.md %}#admin-role) or have been granted [CREATE]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges) or [ZONECONFIG]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges) privileges. To configure [system objects]({% link {{ page.version.version }}/configure-replication-zones.md %}#for-system-data), the user must be a member of the admin role.

For usage, see Synopsis.

ALTER DATABASE .. DROP REGION drops a [region]({% link {{ page.version.version }}/multiregion-overview.md %}#database-regions) from a [multi-region database]({% link {{ page.version.version }}/multiregion-overview.md %}). While CockroachDB processes an index modification or changing a table to or from a [REGIONAL BY ROW table]({% link {{ page.version.version }}/table-localities.md %}#regional-by-row-tables), attempting to drop a region from the database containing that REGIONAL BY ROW table will produce an error. Similarly, while this statement is running, all index modifications and locality changes on [REGIONAL BY ROW]({% link {{ page.version.version }}/table-localities.md %}#regional-by-row-tables) tables will be blocked.

You cannot drop a region from a multi-region database if:

• The region is set as the primary region, unless it is the last remaining region.
• The region is set as the secondary region. To drop the region, you must first unset the secondary region using DROP SECONDARY REGION.
• The database uses the [REGION survival goal]({% link {{ page.version.version }}/multiregion-survival-goals.md %}#survive-region-failures) and there are only three regions configured on the database.

For examples, see Manage regions.

To drop a region from a database, the user must have one of the following:

• Membership to the [admin]({% link {{ page.version.version }}/security-reference/authorization.md %}#roles) role for the cluster.
• Membership to the [owner]({% link {{ page.version.version }}/security-reference/authorization.md %}#object-ownership) role, or the [CREATE privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges), for the database and all [REGIONAL BY ROW]({% link {{ page.version.version }}/table-localities.md %}#regional-by-row-tables) tables in the database.

For usage, see Synopsis.

ALTER DATABASE .. DROP SECONDARY REGION unsets the [secondary region]({% link {{ page.version.version }}/multiregion-overview.md %}#secondary-regions) (if set) from a [multi-region database]({% link {{ page.version.version }}/multiregion-overview.md %}).

The secondary region is used for failover purposes: if the primary region fails, the secondary region acts as the new primary region. For more information, see [Secondary regions]({% link {{ page.version.version }}/multiregion-overview.md %}#secondary-regions).

For examples, see Manage regions.

To unset a secondary region on a database, the user must have one of the following:

• Membership to the [admin]({% link {{ page.version.version }}/security-reference/authorization.md %}#roles) role for the cluster.
• Membership to the [owner]({% link {{ page.version.version }}/security-reference/authorization.md %}#object-ownership) role, or the [CREATE privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges) for the database.

ALTER DATABASE .. DROP SUPER REGION drops a [super region]({% link {{ page.version.version }}/multiregion-overview.md %}#super-regions) from a [multi-region database]({% link {{ page.version.version }}/multiregion-overview.md %}).

{{site.data.alerts.callout_info}} {% include feature-phases/preview.md %} {{site.data.alerts.end}}

{% include {{page.version.version}}/sql/super-region-considerations.md %}

For examples, see Manage super regions.

To drop a super region from a database, the user must have one of the following:

• Membership to the [admin]({% link {{ page.version.version }}/security-reference/authorization.md %}#roles) role for the cluster.
• Either [ownership]({% link {{ page.version.version }}/security-reference/authorization.md %}#object-ownership) or the [CREATE privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges) for the database.

For usage, see Synopsis.

ALTER DATABASE ... OWNER TO is used to change the owner of a database.

For examples, see Change database owner.

To change the owner of a database, the user must be an admin user, or the current owner of the database and a member of the new owner [role]({% link {{ page.version.version }}/security-reference/authorization.md %}#roles). The user must also have the CREATEDB [privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#managing-privileges).

For usage, see Synopsis.

ALTER DATABASE ... PLACEMENT is used to set the replica placement policy (DEFAULT or RESTRICTED) for a [multi-region database]({% link {{ page.version.version }}/multiregion-overview.md %})'s [regional tables]({% link {{ page.version.version }}/regional-tables.md %}). [Regional tables]({% link {{ page.version.version }}/regional-tables.md %}) are those with [REGIONAL BY ROW]({% link {{ page.version.version }}/table-localities.md %}#regional-by-row-tables) or [REGIONAL BY TABLE]({% link {{ page.version.version }}/table-localities.md %}#regional-tables) localities.

ALTER DATABASE ... PLACEMENT RESTRICTED constrains the voting and non-voting replica placement for the database's tables to the [home regions]({% link {{ page.version.version }}/alter-table.md %}#crdb_region) associated with those tables. This is a way of opting out of [non-voting replicas]({% link {{ page.version.version }}/architecture/replication-layer.md %}#non-voting-replicas) for [regional tables]({% link {{ page.version.version }}/regional-tables.md %}) to accomplish one or more of the following goals:

• Implement a [data domiciling]({% link {{ page.version.version }}/data-domiciling.md %}) strategy.
• Reduce the amount of data stored on the cluster.
• Reduce the overhead of replicating data across a large number of regions (e.g., 10 or more) for databases with heavier write loads.

Note that ALTER DATABASE ... PLACEMENT RESTRICTED does not allow you to opt out of placing [non-voting replicas]({% link {{ page.version.version }}/architecture/replication-layer.md %}#non-voting-replicas) entirely. For example, [GLOBAL tables]({% link {{ page.version.version }}/global-tables.md %}) in the database will remain unaffected by this statement. GLOBAL tables are designed to have replicas placed across all available [cluster regions]({% link {{ page.version.version }}/multiregion-overview.md %}#cluster-regions) to ensure fast local reads.

For examples, see Set replica placement policy.

To use this statement, the user must have one of the following:

• Membership to the [admin]({% link {{ page.version.version }}/security-reference/authorization.md %}#roles) role for the cluster.
• [Ownership]({% link {{ page.version.version }}/security-reference/authorization.md %}#object-ownership) or the [CREATE privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges) for the database and all tables in the database.

For usage, see Synopsis.

The replica placement policies work as follows:

• DEFAULT (Default): If the replica placement policy is set to DEFAULT, CockroachDB will use its default replica placement settings, which mean that:

  • Data will be placed in as many regions as necessary to ensure your [database survival goals]({% link {{ page.version.version }}/multiregion-overview.md %}#survival-goals) are met.
  • You can get fast stale reads from all [database regions]({% link {{ page.version.version }}/multiregion-overview.md %}#database-regions).

• RESTRICTED: If the replica placement policy is set to RESTRICTED, CockroachDB will constrain replica placement to only those regions where the table has voting replicas (that is, replicas which participate in the [Raft quorum]({% link {{ page.version.version }}/architecture/replication-layer.md %}#raft)). In practice, this means that voting replicas for the table will be constrained to the table's [home region]({% link {{ page.version.version }}/multiregion-overview.md %}#table-localities). Specifically, for [REGIONAL BY TABLE]({% link {{ page.version.version }}/table-localities.md %}#regional-tables) tables, it will only place replicas in the defined region (or the database's primary region); for [REGIONAL BY ROW]({% link {{ page.version.version }}/table-localities.md %}#regional-by-row-tables) tables, it will only place replicas for each underlying [partition]({% link {{ page.version.version }}/partitioning.md %}) in the partition's specified region. Finally, note that:

  • Regional tables with this placement setting will no longer provide "fast stale reads" from other (non-home) regions, since fast stale reads rely on the presence of non-voting replicas.
  • The RESTRICTED replica placement policy is only available for databases with the [ZONE survival goal]({% link {{ page.version.version }}/multiregion-survival-goals.md %}#survive-zone-failures).
  • This setting does not affect how [GLOBAL tables]({% link {{ page.version.version }}/global-tables.md %}) work; they will still place replicas in all [database regions]({% link {{ page.version.version }}/multiregion-overview.md %}#database-regions).

ALTER DATABASE ... RENAME TO changes the name of a database.

{{site.data.alerts.callout_info}} It is not possible to rename a database if the database is referenced by a [view]({% link {{ page.version.version }}/views.md %}). For more details, see [View Dependencies]({% link {{ page.version.version }}/views.md %}#view-dependencies). {{site.data.alerts.end}}

For examples, see Rename database.

To rename a database, the user must be a member of the admin role or must have the [CREATEDB]({% link {{ page.version.version }}/create-role.md %}#create-a-role-that-can-create-and-rename-databases) parameter set.

For usage, see Synopsis.

ALTER DATABASE ... RESET {session variable} resets a [session variable]({% link {{ page.version.version }}/set-vars.md %}#supported-variables) for a database to its default value for the client session.

{% include {{page.version.version}}/sql/show-default-session-variables-for-role.md %}

No [privileges]({% link {{ page.version.version }}/security-reference/authorization.md %}#managing-privileges) are required to reset a session setting.

For usage, see Synopsis.

In CockroachDB, the following are aliases for ALTER DATABASE ... RESET {session variable}:

• [ALTER ROLE ALL IN DATABASE ... RESET {session variable}]({% link {{ page.version.version }}/alter-role.md %})

ALTER DATABASE ... SET {session variable} sets the default value of a [session variable]({% link {{ page.version.version }}/set-vars.md %}#supported-variables) for all future sessions on the database. This command does not alter the session setting of the current session.

{% include {{page.version.version}}/sql/show-default-session-variables-for-role.md %}

To set the role session variable, the current user must be a member of the admin role, or a member of the target role.

All other session variables do not require [privileges]({% link {{ page.version.version }}/security-reference/authorization.md %}#managing-privileges) to modify.

For usage, see Synopsis.

In CockroachDB, the following are aliases for ALTER DATABASE ... SET {session variable}:

• ALTER ROLE ALL IN DATABASE ... SET {session variable}

ALTER DATABASE .. SET PRIMARY REGION sets the primary [region]({% link {{ page.version.version }}/multiregion-overview.md %}#database-regions) of a [multi-region database]({% link {{ page.version.version }}/multiregion-overview.md %}).

{{site.data.alerts.callout_danger}} If a database's [zone configuration]({% link {{ page.version.version }}/configure-replication-zones.md %}) has been directly set with an ALTER DATABASE ... CONFIGURE ZONE statement, CockroachDB will block all ALTER DATABASE ... SET PRIMARY REGION statements on the database.

To remove existing, manually-configured zones from a database (and unblock SET PRIMARY REGION statements on the database), use an ALTER DATABASE ... CONFIGURE ZONE DISCARD statement. {{site.data.alerts.end}}

[Secondary regions]({% link {{ page.version.version }}/multiregion-overview.md %}#secondary-regions) allow you to define a [database region]({% link {{ page.version.version }}/multiregion-overview.md %}#database-regions) that will be used for failover in the event your primary region goes down. For more information, see [Secondary regions]({% link {{ page.version.version }}/multiregion-overview.md %}#secondary-regions).

For examples, see Manage regions.

To add a primary region to a database with no existing regions, the user must have one of the following:

• Membership to the [admin]({% link {{ page.version.version }}/security-reference/authorization.md %}#roles) role for the cluster.
• Membership to the [owner]({% link {{ page.version.version }}/security-reference/authorization.md %}#object-ownership) role, or the [CREATE privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges), for the database and all tables in the database.

To switch primary regions to a region that has already been added to a database, the user must have membership to the [owner]({% link {{ page.version.version }}/security-reference/authorization.md %}#object-ownership) role for the database, or have the [CREATE privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges) on the database.

For usage, see Synopsis.

ALTER DATABASE .. SET SECONDARY REGION adds a [secondary region]({% link {{ page.version.version }}/multiregion-overview.md %}#database-regions) to a [multi-region database]({% link {{ page.version.version }}/multiregion-overview.md %}) for failover purposes.

If the primary region fails, the secondary region becomes the new primary region. For more information, see [Secondary regions]({% link {{ page.version.version }}/multiregion-overview.md %}#secondary-regions).

{{site.data.alerts.callout_danger}} In order to add a secondary region with ALTER DATABASE ... SET SECONDARY REGION, you must first set a primary database region with SET PRIMARY REGION, or when [creating the database]({% link {{ page.version.version }}/create-database.md %}). For an example showing how to add a secondary region with ALTER DATABASE, see Set the secondary region. {{site.data.alerts.end}}

For examples, see Manage regions.

To add a secondary region to a database, the user must have one of the following:

• Membership to the [admin]({% link {{ page.version.version }}/security-reference/authorization.md %}#admin-role) role for the cluster.
• Either [ownership]({% link {{ page.version.version }}/security-reference/authorization.md %}#object-ownership) or the [CREATE privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges) for the database.

For usage, see Synopsis.

ALTER DATABASE ... SURVIVE {ZONE,REGION} FAILURE [statement]({% link {{ page.version.version }}/sql-statements.md %}) sets the [survival goal]({% link {{ page.version.version }}/multiregion-overview.md %}#survival-goals) for a [multi-region database]({% link {{ page.version.version }}/multiregion-overview.md %}).

For examples, see Configure survival goals.

The user must be a member of the [admin]({% link {{ page.version.version }}/security-reference/authorization.md %}#roles) or [owner]({% link {{ page.version.version }}/security-reference/authorization.md %}#object-ownership) roles, or have the [CREATE privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#supported-privileges) on the database.

For usage, see Synopsis.

{% include {{page.version.version}}/sql/multiregion-example-setup.md %}

Suppose you want to make the database movr a multi-region database.

To add the first region to the database, or to set an already-added region as the primary region, use a SET PRIMARY REGION statement:

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr SET PRIMARY REGION "us-east1";

ALTER DATABASE PRIMARY REGION

Given a cluster with multiple regions, any databases in that cluster that have not yet had their primary regions set will have their replicas spread as broadly as possible for resiliency. When a primary region is added to one of these databases:

• All tables will be [REGIONAL BY TABLE]({% link {{ page.version.version }}/alter-table.md %}#regional-by-table) in the primary region by default.
• This means that all such tables will have all of their voting replicas and leaseholders moved to the primary region. This process is known as [rebalancing]({% link {{ page.version.version }}/architecture/replication-layer.md %}#leaseholder-rebalancing).

To add more regions to a database that already has at least one region:

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr ADD region "us-west1";

ALTER DATABASE ADD REGION

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr ADD region "europe-west1";

ALTER DATABASE ADD REGION

To view the regions associated with a multi-region database, use a [SHOW REGIONS FROM DATABASE]({% link {{ page.version.version }}/show-regions.md %}) statement:

{% include_cached copy-clipboard.html %}

SHOW REGIONS FROM DATABASE movr;

  database |    region    | primary | secondary |  zones
-----------+--------------+---------+-----------+----------
  movr     | us-east1     |    t    |     f     | {b,c,d}
  movr     | europe-west1 |    f    |     f     | {b,c,d}
  movr     | us-west1     |    f    |     f     | {a,b,c}
(3 rows)

To set an existing [database region]({% link {{ page.version.version }}/multiregion-overview.md %}#database-regions) (that is not already the primary region) as the [secondary region]({% link {{ page.version.version }}/multiregion-overview.md %}#secondary-regions), use the following statement:

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr SET SECONDARY REGION "us-west1";

ALTER DATABASE SET SECONDARY REGION

Now, the "us-west1" region will act as the primary region if the original primary region fails.

To unset an existing [database region]({% link {{ page.version.version }}/multiregion-overview.md %}#database-regions) as the [secondary region]({% link {{ page.version.version }}/multiregion-overview.md %}#secondary-regions) on a multi-region database, use the DROP SECONDARY REGION statement:

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr DROP SECONDARY REGION;

ALTER DATABASE DROP SECONDARY REGION

{{site.data.alerts.callout_info}} This statement does not drop the region from the database. To drop a region, use DROP REGION. {{site.data.alerts.end}}

To change the primary region to another region in the database, use a SET PRIMARY REGION statement.

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr SET PRIMARY REGION "europe-west1";

ALTER DATABASE PRIMARY REGION

You can only change an existing primary region to a region that has already been added to the database. If you try to change the primary region to a region that is not already associated with a database, CockroachDB will return an error.

To drop a region from a multi-region database, use a DROP REGION statement.

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr DROP REGION "us-east1";

ALTER DATABASE DROP REGION

You cannot drop a region from a multi-region database if:

• The region is set as the primary region, unless it is the last remaining region.
• The region is set as the secondary region. To drop the region, you must first unset the secondary region using DROP SECONDARY REGION.
• The database uses the [REGION survival goal]({% link {{ page.version.version }}/multiregion-survival-goals.md %}#survive-region-failures) and there are only three regions configured on the database.

{% include {{page.version.version}}/sql/multiregion-example-setup.md %}

{% include {{page.version.version}}/sql/multiregion-movr-add-regions.md %}

{% include {{page.version.version}}/sql/multiregion-movr-global.md %}

{% include {{page.version.version}}/sql/multiregion-movr-regional-by-row.md %}

{% include {{page.version.version}}/sql/enable-super-regions.md %}

To add a super region to a multi-region database, use the ALTER DATABASE ... ADD SUPER REGION statement:

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr ADD SUPER REGION "usa" VALUES "us-east1", "us-west1";

ALTER DATABASE ADD SUPER REGION

This example assumes you have already added a "usa" super region as shown in the example Add a super region to a database. If you wanted to drop the region us-west1, you would first need to remove it from the super region.

To remove a region from a super region, use the ALTER DATABASE ... ALTER SUPER REGION statement and list only the regions that should remain in the super region:

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr ALTER SUPER REGION "usa" VALUES "us-east1";

ALTER DATABASE ALTER SUPER REGION

To add a region to a super region, alter the super region as shown above to be a list of regions that includes the existing and the new regions.

{% include {{page.version.version}}/sql/enable-super-region-primary-region-changes.md %}

To drop a super region from a multi-region database, use a DROP SUPER REGION statement:

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr DROP SUPER REGION "usa";

ALTER DATABASE DROP SUPER REGION

Note that you cannot drop a region that is part of a super region until you either alter the super region to remove it, or drop the super region altogether.

For example, using the super region that was added in ADD SUPER REGION:

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr DROP REGION "us-west1";

ERROR: region us-west1 is part of super region usa
SQLSTATE: 2BP01
HINT: you must first drop super region usa before you can drop the region us-west1

{% include {{ page.version.version }}/sql/movr-statements-geo-partitioned-replicas.md %}

{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-database.md %}

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr CONFIGURE ZONE USING range_min_bytes = 0, range_max_bytes = 90000, gc.ttlseconds = 89999, num_replicas = 4;

{{site.data.alerts.callout_info}} When you discard a zone configuration, the objects it was applied to will then inherit a configuration from an object "the next level up"; e.g., if the object whose configuration is being discarded is a table, it will use its parent database's configuration.

You cannot DISCARD any zone configurations on multi-region tables, indexes, or partitions if the [multi-region abstractions]({% link {{ page.version.version }}/migrate-to-multiregion-sql.md %}#replication-zone-patterns-and-multi-region-sql-abstractions) created the zone configuration. {{site.data.alerts.end}}

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr CONFIGURE ZONE DISCARD;

The following examples show:

• How to override specific fields of a schema object's zone configs.
• How something like the [Secondary regions]({% link {{ page.version.version }}/multiregion-overview.md %}#secondary-regions) multi-region abstraction could have been implemented using Zone Config Extensions. For this example, we will call it "Failover regions".
• How to reset a region's Zone Config Extensions.
• How to discard a region's Zone Config Extensions.
• How you could implement super regions.
• How to minimize cross-region write latency.

{{site.data.alerts.callout_info}} We strongly recommend using the multi-region abstractions over "rolling your own" using Zone Config Extensions. These examples are provided to show the flexibility of Zone Config Extensions. {{site.data.alerts.end}}

The setup described in this section will be used in the following examples.

Start a [cockroach demo]({% link {{ page.version.version }}/cockroach-demo.md %}) cluster as follows:

{% include_cached copy-clipboard.html %}

cockroach demo --global --nodes=9

This gives us a (preloaded) [MovR]({% link {{ page.version.version }}/movr.md %}) database on a cluster with the following [regions]({% link {{ page.version.version }}/multiregion-overview.md %}#cluster-regions), which can be viewed with [SHOW REGIONS]({% link {{ page.version.version }}/show-regions.md %}):

{% include_cached copy-clipboard.html %}

SHOW REGIONS;

     region    |  zones  | database_names | primary_region_of | secondary_region_of
---------------+---------+----------------+-------------------+----------------------
  europe-west1 | {b,c,d} | {}             | {}                | {}
  us-east1     | {b,c,d} | {}             | {}                | {}
  us-west1     | {a,b,c} | {}             | {}                | {}
(3 rows)

Next, modify the database to use the [multi-region abstractions]({% link {{ page.version.version }}/multiregion-overview.md %}) as follows:

1. Set the primary region using SET PRIMARY REGION.
2. Add the other two regions using ADD REGION.

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr SET PRIMARY REGION "us-east1";

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr ADD REGION "us-west1";

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr ADD REGION "europe-west1";

In this example we will configure a multi-region [MovR]({% link {{ page.version.version }}/movr.md %}) database to update its [lease_preferences]({% link {{ page.version.version }}/configure-replication-zones.md %}#lease_preferences) field.

Setting the primary region to us-east1 during the setup steps added us-east1 to lease_preferences.

{% include_cached copy-clipboard.html %}

SHOW ZONE CONFIGURATION FROM DATABASE movr;

     target     |                                      raw_config_sql
----------------+-------------------------------------------------------------------------------------------
  DATABASE movr | ALTER DATABASE movr CONFIGURE ZONE USING
                |     range_min_bytes = 134217728,
                |     range_max_bytes = 536870912,
                |     gc.ttlseconds = 90000,
                |     num_replicas = 5,
                |     num_voters = 3,
                |     constraints = '{+region=europe-west1: 1, +region=us-east1: 1, +region=us-west1: 1}',
                |     voter_constraints = '[+region=us-east1]',
                |     lease_preferences = '[[+region=us-east1]]'
(1 row)

We will now use ALTER DATABASE ... ALTER LOCALITY to overwrite the lease_preferences field to add us-west1 to the list of regions:

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr ALTER LOCALITY REGIONAL IN "us-east1" CONFIGURE ZONE USING lease_preferences = '[[+region=us-east1], [+region=us-west1]]';

To view the updated zone configs, enter the following statement:

{% include_cached copy-clipboard.html %}

SHOW ZONE CONFIGURATION FROM DATABASE movr;

     target     |                                      raw_config_sql
----------------+-------------------------------------------------------------------------------------------
  DATABASE movr | ALTER DATABASE movr CONFIGURE ZONE USING
                |     range_min_bytes = 134217728,
                |     range_max_bytes = 536870912,
                |     gc.ttlseconds = 90000,
                |     num_replicas = 5,
                |     num_voters = 3,
                |     constraints = '{+region=europe-west1: 1, +region=us-east1: 1, +region=us-west1: 1}',
                |     voter_constraints = '[+region=us-east1]',
                |     lease_preferences = '[[+region=us-east1], [+region=us-west1]]'
(1 row)

The lease_preferences field is now updated to include us-west1.

To remove the changes made in this example, reset the Zone Config Extensions.

In this example, [Zone Config Extensions]({% link {{ page.version.version }}/zone-config-extensions.md %}) are used to provide an alternative implementation of [super regions]({% link {{ page.version.version }}/multiregion-overview.md %}#super-regions), which are useful for [data domiciling]({% link {{ page.version.version }}/data-domiciling.md %}).

For this example, you need to start a [cockroach demo cluster]({% link {{ page.version.version }}/cockroach-demo.md %}) using the following command, which [defines the available cluster localities using the --demo-locality flag]({% link {{ page.version.version }}/cockroach-demo.md %}#demo-locality):

{% include_cached copy-clipboard.html %}

cockroach demo --nodes=9 --demo-locality=region=us-east1:region=us-east1:region=us-central1:region=us-west1:region=europe-west1:region=europe-west1:region=europe-central1:region=europe-east1:region=europe-east1

Next, enter the following statements at the SQL prompt. These statements will:

• Make the [movr database]({% link {{ page.version.version }}/movr.md %}) into a [multi-region database]({% link {{ page.version.version }}/multiregion-overview.md %}) by [setting the primary region]({% link {{ page.version.version }}/alter-database.md %}#set-primary-region).
• Set the movr database to [survive region failures]({% link {{ page.version.version }}/multiregion-survival-goals.md %}#survive-region-failures).
• Add the remaining regions defined at cluster start time to the multi-region movr database (for a total of 6).

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr SET PRIMARY REGION "us-east1";
ALTER DATABASE movr ADD REGION "us-central1";
ALTER DATABASE movr ADD REGION "us-west1";
ALTER DATABASE movr ADD REGION "europe-west1";
ALTER DATABASE movr ADD REGION "europe-central1";
ALTER DATABASE movr ADD REGION "europe-east1";
ALTER DATABASE movr SURVIVE REGION FAILURE;

Now that the multi-region cluster is configured, we will use the following ALTER LOCALITY statements to [configure replication zones]({% link {{ page.version.version }}/configure-replication-zones.md %}) such that:

• [Replicas]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-replica) in the us-east1 region are only stored on nodes in the US.
• Replicas in the europe-central1 region are only stored on nodes in the EU.

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr ALTER LOCALITY REGIONAL IN "us-east1" CONFIGURE ZONE USING
    num_replicas = 7,
    constraints = '{+region=us-east1: 3,
                    +region=us-central1: 3,
                    +region=us-west1: 1}',
    lease_preferences = '[[+region=us-east1], [+region=us-central1]]';

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr ALTER LOCALITY REGIONAL IN "europe-central1" CONFIGURE ZONE USING
    num_replicas = 7,
    constraints = '{+region=europe-central1: 3,
                    +region=europe-west1: 3,
                    +region=europe-east1: 1}',
    lease_preferences = '[[+region=europe-central1], [+region=europe-west1]]';

In this example, [Zone Config Extensions]({% link {{ page.version.version }}/zone-config-extensions.md %}) are used to minimize cross-region write latency in a cluster with the following characteristics:

• Three main US regions (us-west1,us-east1,us-central1).
• Two additional distant regions (europe-west1, asia-northeast1). Only [follower reads]({% link {{ page.version.version }}/follower-reads.md %}) will be made from these regions.

To minimize the cross-region write latency, [configure replication zones]({% link {{ page.version.version }}/configure-replication-zones.md %}) such that the 3 US regions have voting replicas (that is, replicas that participate in [Raft quorum]({% link {{ page.version.version }}/architecture/replication-layer.md %}#raft)). This will leave the 2 additional non-US regions with only [non-voting replicas]({% link {{ page.version.version }}/architecture/replication-layer.md %}#non-voting-replicas).

For this example, you need to start a [cockroach demo cluster]({% link {{ page.version.version }}/cockroach-demo.md %}) using the following command, which [defines the available cluster localities using the --demo-locality flag]({% link {{ page.version.version }}/cockroach-demo.md %}#demo-locality):

{% include_cached copy-clipboard.html %}

cockroach demo --nodes=5 --demo-locality=region=us-east1:region=us-west1:region=us-central1:region=europe-west1:region=asia-northeast1

Next, enter the following statements at the SQL prompt. These statements will:

• Make the [movr database]({% link {{ page.version.version }}/movr.md %}) into a [multi-region database]({% link {{ page.version.version }}/multiregion-overview.md %}) by [setting the primary region]({% link {{ page.version.version }}/alter-database.md %}#set-primary-region).
• Set the movr database to [survive region failures]({% link {{ page.version.version }}/multiregion-survival-goals.md %}#survive-region-failures).
• Add the remaining regions defined at cluster start time to the multi-region movr database (for a total of 5).

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr SET PRIMARY REGION "us-west1";
ALTER DATABASE movr ADD REGION "us-central1";
ALTER DATABASE movr ADD REGION "us-east1";
ALTER DATABASE movr ADD REGION "europe-west1";
ALTER DATABASE movr ADD REGION "asia-northeast1";
ALTER DATABASE movr SURVIVE REGION FAILURE;

By default, all tables in the movr database are [REGIONAL tables]({% link {{ page.version.version }}/regional-tables.md %}):

{% include_cached copy-clipboard.html %}

SHOW TABLES;

  schema_name |         table_name         | type  | owner | estimated_row_count |              locality
--------------+----------------------------+-------+-------+---------------------+--------------------------------------
  public      | promo_codes                | table | demo  |                1000 | REGIONAL BY TABLE IN PRIMARY REGION
  public      | rides                      | table | demo  |                 500 | REGIONAL BY TABLE IN PRIMARY REGION
  public      | user_promo_codes           | table | demo  |                   5 | REGIONAL BY TABLE IN PRIMARY REGION
  public      | users                      | table | demo  |                  50 | REGIONAL BY TABLE IN PRIMARY REGION
  public      | vehicle_location_histories | table | demo  |                1000 | REGIONAL BY TABLE IN PRIMARY REGION
  public      | vehicles                   | table | demo  |                  15 | REGIONAL BY TABLE IN PRIMARY REGION
(6 rows)

Now that the multi-region cluster is configured, we will use the following ALTER LOCALITY statements to [configure replication zones]({% link {{ page.version.version }}/configure-replication-zones.md %}) such that:

• The 3 US regions have voting replicas (that is, replicas that participate in [Raft quorum]({% link {{ page.version.version }}/architecture/replication-layer.md %}#raft)).
• The 2 additional regions (Europe and Japan) are left with only [non-voting replicas]({% link {{ page.version.version }}/architecture/replication-layer.md %}#non-voting-replicas) that can be used to serve [follower reads]({% link {{ page.version.version }}/follower-reads.md %}).

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr ALTER LOCALITY REGIONAL CONFIGURE ZONE USING voter_constraints = '{+region=us-west1: 2, +region=us-central1: 2, +region=us-east1: 1}';

In this example we will use Zone Config Extensions to configure a multi-region [MovR]({% link {{ page.version.version }}/movr.md %}) database so that if the primary region fails, enough [replicas]({% link {{ page.version.version }}/architecture/distribution-layer.md %}) will be found in another region (the "failover" region) to take over for the primary region. We will set the locality scope for this configuration to be REGIONAL IN, which covers all [REGIONAL BY TABLE IN {region} tables]({% link {{ page.version.version }}/alter-table.md %}#set-the-table-locality-to-regional-by-table) and all {region} [partitions]({% link {{ page.version.version }}/partitioning.md %}) of [REGIONAL BY ROW tables]({% link {{ page.version.version }}/alter-table.md %}#set-the-table-locality-to-regional-by-row).

{{site.data.alerts.callout_info}} This functionality is already provided by the built-in [Secondary regions]({% link {{ page.version.version }}/multiregion-overview.md %}#secondary-regions) feature. It is used here to show the flexibility of Zone Config Extensions. We strongly recommend using the [built-in multi-region features]({% link {{ page.version.version }}/multiregion-overview.md %}) whenever possible. {{site.data.alerts.end}}

1. Set the database to have a REGION survival goal using [ALTER DATABASE ... SURVIVE REGION FAILURE]({% link {{ page.version.version }}/alter-database.md %}#survive-zone-region-failure):

   {% include_cached copy-clipboard.html %}

   ALTER DATABASE movr SURVIVE REGION FAILURE;

2. Apply the REGIONAL BY ROW locality to the movr.rides table using the following statement:

   {% include_cached copy-clipboard.html %}

   ALTER TABLE rides ADD COLUMN region crdb_internal_region AS (
    CASE WHEN city = 'amsterdam' THEN 'europe-west1'
         WHEN city = 'paris' THEN 'europe-west1'
         WHEN city = 'rome' THEN 'europe-west1'
         WHEN city = 'new york' THEN 'us-east1'
         WHEN city = 'boston' THEN 'us-east1'
         WHEN city = 'washington dc' THEN 'us-east1'
         WHEN city = 'san francisco' THEN 'us-west1'
         WHEN city = 'seattle' THEN 'us-west1'
         WHEN city = 'los angeles' THEN 'us-west1'
    END
   ) STORED;
   ALTER TABLE rides ALTER COLUMN region SET NOT NULL;
   ALTER TABLE rides SET LOCALITY REGIONAL BY ROW AS "region";

3. View the [zone configs]({% link {{ page.version.version }}/configure-replication-zones.md %}) for the movr.rides table using [SHOW ZONE CONFIGURATION]({% link {{ page.version.version }}/show-zone-configurations.md %}):

   {% include_cached copy-clipboard.html %}

   SHOW ZONE CONFIGURATION FROM TABLE movr.rides;

        target     |                                      raw_config_sql
   ----------------+-------------------------------------------------------------------------------------------
     DATABASE movr | ALTER DATABASE movr CONFIGURE ZONE USING
                   |     range_min_bytes = 134217728,
                   |     range_max_bytes = 536870912,
                   |     gc.ttlseconds = 90000,
                   |     num_replicas = 5,
                   |     num_voters = 5,
                   |     constraints = '{+region=europe-west1: 1, +region=us-east1: 1, +region=us-west1: 1}',
                   |     voter_constraints = '{+region=us-east1: 2}',
                   |     lease_preferences = '[[+region=us-east1]]'
   (1 row)
   

   Remember that we configured us-east1 to be our primary region during cluster setup. The output above confirms that us-east1 is the primary region based on the values of the [voter_constraints]({% link {{ page.version.version }}/configure-replication-zones.md %}#voter_constraints) and [lease_preferences]({% link {{ page.version.version }}/configure-replication-zones.md %}#lease_preferences) keys.

4. Update the configuration to keep additional voting replicas and leaseholders in us-west1. We do this because we would like to configure us-west1 to be the failover region for us-east1. The following SQL statement accomplishes this by configuring us-east1 to keep additional voting replicas and leaseholders in us-west1. This means that if us-east1 fails, it will fail over to us-west1.

   {% include_cached copy-clipboard.html %}

   ALTER DATABASE movr ALTER LOCALITY REGIONAL IN "us-east1" CONFIGURE ZONE USING voter_constraints = '{+region=us-east1: 2, +region=us-west1: 2}', lease_preferences = '[[+region=us-east1], [+region=us-west1]]';

5. View the [zone configs]({% link {{ page.version.version }}/configure-replication-zones.md %}) for the movr.rides table using [SHOW ZONE CONFIGURATION]({% link {{ page.version.version }}/show-zone-configurations.md %}):

   {% include_cached copy-clipboard.html %}

   SHOW ZONE CONFIGURATION FROM TABLE movr.rides;

        target     |                                      raw_config_sql
   ----------------+-------------------------------------------------------------------------------------------
     DATABASE movr | ALTER DATABASE movr CONFIGURE ZONE USING
                   |     range_min_bytes = 134217728,
                   |     range_max_bytes = 536870912,
                   |     gc.ttlseconds = 90000,
                   |     num_replicas = 5,
                   |     num_voters = 5,
                   |     constraints = '{+region=europe-west1: 1, +region=us-east1: 1, +region=us-west1: 1}',
                   |     voter_constraints = '{+region=us-east1: 2, +region=us-west1: 2}',
                   |     lease_preferences = '[[+region=us-east1], [+region=us-west1]]'
   (1 row)
   

   The following changes are shown: - There are now 2 voting replicas stored in us-west1. - There is now a preference that if leases cannot be placed in us-east1, they should be placed in us-west1.

   Both of these changes combine to ensure that if us-east1 goes down, the cluster will still be able to operate until some mitigation is in place.

To remove the zone config changes made in this example, reset the Zone Config Extensions.

To reset the Zone Config Extension configuration applied to a region to the default settings, enter the following statement:

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr ALTER LOCALITY CONFIGURE ZONE USING DEFAULT;

{{site.data.alerts.callout_info}} This will not reset any configuration created by the [multi-region abstractions]({% link {{ page.version.version }}/multiregion-overview.md %}). {{site.data.alerts.end}}

To discard the Zone Config Extension settings from a region, enter the following statement:

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr ALTER LOCALITY CONFIGURE ZONE DISCARD;

{{site.data.alerts.callout_info}} When you discard a zone configuration, the objects it was applied to will then inherit a configuration from an object "the next level up"; e.g., if the object whose configuration is being discarded is a table, it will use its parent database's configuration.

However, this statement will not remove any configuration created by the [multi-region abstractions]({% link {{ page.version.version }}/multiregion-overview.md %}). {{site.data.alerts.end}}

{% include {{page.version.version}}/sql/movr-statements.md %}

Suppose that the current owner of the movr database is root and you want to change the owner to a new user named max.

{% include_cached copy-clipboard.html %}

> ALTER DATABASE movr OWNER TO max;

To verify that the owner is now max, query the pg_catalog.pg_database and pg_catalog.pg_roles tables:

{% include_cached copy-clipboard.html %}

> SELECT rolname FROM pg_catalog.pg_database d JOIN pg_catalog.pg_roles r ON d.datdba = r.oid WHERE datname = 'movr';

  rolname
-----------
  max
(1 row)

{{site.data.alerts.callout_info}} If the user running the command is not an admin user, they must own the database and be a member of the new owning role. They must also have the CREATEDB [privilege]({% link {{ page.version.version }}/security-reference/authorization.md %}#managing-privileges). {{site.data.alerts.end}}

To follow along with the examples below:

1. Start a [demo cluster]({% link {{ page.version.version }}/cockroach-demo.md %}) with the [--global flag]({% link {{ page.version.version }}/cockroach-demo.md %}#general) to simulate a multi-region cluster:

   {% include_cached copy-clipboard.html %}

   cockroach demo --global --nodes 9

2. Set the demo cluster's [database regions]({% link {{ page.version.version }}/multiregion-overview.md %}#database-regions) and [table localities]({% link {{ page.version.version }}/multiregion-overview.md %}#table-locality) as described in [Low Latency Reads and Writes in a Multi-Region Cluster]({% link {{ page.version.version }}/demo-low-latency-multi-region-deployment.md %}) (specifically, starting at [Step 5. Execute multi-region SQL statements]({% link {{ page.version.version }}/demo-low-latency-multi-region-deployment.md %}#step-5-execute-multi-region-sql-statements)).

3. Enable the replica placement syntax with either the [session variable]({% link {{ page.version.version }}/set-vars.md %}) or the [cluster setting]({% link {{ page.version.version }}/cluster-settings.md %}) as shown below.

   1. To use the session variable:

      {% include_cached copy-clipboard.html %}

      SET enable_multiregion_placement_policy = on;

   2. To use the cluster setting:

      {% include_cached copy-clipboard.html %}

      SET CLUSTER SETTING sql.defaults.multiregion_placement_policy.enabled = on;

{% include {{page.version.version}}/sql/sql-defaults-cluster-settings-deprecation-notice.md %}

If you know at database creation time that you'd like to set the database's replica placement policy to "restricted", you can do so in a [CREATE DATABASE]({% link {{ page.version.version }}/create-database.md %}) statement as shown below:

{% include_cached copy-clipboard.html %}

CREATE DATABASE movr2 PRIMARY REGION "us-east1" REGIONS "us-west1", "europe-west1" PLACEMENT RESTRICTED;

CREATE DATABASE

When you set the database's placement policy to RESTRICTED, you are saying that you want the underlying data to be restricted to the table or partition's [home region]({% link {{ page.version.version }}/multiregion-overview.md %}#table-localities).

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr PLACEMENT RESTRICTED;

ALTER DATABASE PLACEMENT

If previously you set the replica placement policy to RESTRICTED, you can set it back to the default by issuing the following statement:

{% include_cached copy-clipboard.html %}

ALTER DATABASE movr PLACEMENT DEFAULT;

ALTER DATABASE PLACEMENT

{% include_cached copy-clipboard.html %}

> CREATE DATABASE db1;

{% include_cached copy-clipboard.html %}

> SHOW DATABASES;

  database_name
-----------------
  db1
  defaultdb
  movr
  postgres
  system
(5 rows)

{% include_cached copy-clipboard.html %}

> ALTER DATABASE db1 RENAME TO db2;

{% include_cached copy-clipboard.html %}

> SHOW DATABASES;

  database_name
-----------------
  db2
  defaultdb
  movr
  postgres
  system
(5 rows)

To change the survival goal of a multi-region database to survive zone failures, use the following statement:

{% include_cached copy-clipboard.html %}

ALTER DATABASE {db} SURVIVE ZONE FAILURE;

ALTER DATABASE SURVIVE

{{site.data.alerts.callout_info}} Surviving zone failures is the default setting for multi-region databases. {{site.data.alerts.end}}

For more information about the zone survival goal, see [Surviving zone failures]({% link {{ page.version.version }}/multiregion-survival-goals.md %}#survive-zone-failures).

To change the survival goal of a multi-region database to survive region failures, use the following statement:

{% include_cached copy-clipboard.html %}

ALTER DATABASE {db} SURVIVE REGION FAILURE;

ALTER DATABASE SURVIVE

If you try to change a database with less than 3 [database regions]({% link {{ page.version.version }}/multiregion-overview.md %}#database-regions) to survive region failures, the following error will be signalled:

ERROR: at least 3 regions are required for surviving a region failure
SQLSTATE: 42602
HINT: you must add additional regions to the database using ALTER DATABASE mr ADD REGION <region_name>

For more information about the region survival goal, see [Surviving region failures]({% link {{ page.version.version }}/multiregion-survival-goals.md %}#survive-region-failures).

• [Multi-Region Capabilities Overview]({% link {{ page.version.version }}/multiregion-overview.md %})
• [Secondary regions]({% link {{ page.version.version }}/multiregion-overview.md %}#secondary-regions)
• [Super regions]({% link {{ page.version.version }}/multiregion-overview.md %}#super-regions)
• [Zone Config Extensions]({% link {{ page.version.version }}/zone-config-extensions.md %})
• [Data Domiciling with CockroachDB]({% link {{ page.version.version }}/data-domiciling.md %})
• [CREATE DATABASE]({% link {{ page.version.version }}/create-database.md %})
• [CREATE TABLE]({% link {{ page.version.version }}/create-table.md %})
• [ALTER TABLE]({% link {{ page.version.version }}/alter-table.md %})
• [Online Schema Changes]({% link {{ page.version.version }}/online-schema-changes.md %})
• [SQL Statements]({% link {{ page.version.version }}/sql-statements.md %})