[pull] master from supabase:master

apps/docs/content/guides/deployment/branching.mdx

@@ -580,7 +580,7 @@ With the Supabase branching integration, you can sync the Git branch used by the
 
 ### Vercel
 
-<Admonition type="note" label="Vercel Branching support is in development.">
+<Admonition type="note" label="Vercel Marketplace support.">
 
     The Vercel Integration for Supabase branching is working only with Supabase managed projects. There is currently no support for Vercel Marketplace managed resources, however the support is planned in the future.
 
@@ -598,10 +598,12 @@ For branching to work with Vercel, you also need the [Vercel GitHub integration]
 </Admonition>
 
 Supabase automatically updates your Vercel project with the correct environment variables for the corresponding preview branches.
+The synchronization happens at the time of Pull Request being opened, not at the time of branch creation.
+As branching integration is tied to the Preview Deployments feature in Vercel, there are possible race conditions between Supabase setting correct variables, and Vercel running a deployment process. Because of that, Supabase is always automatically re-deploying the most recent deployment of the given pull request.
 
-### Netlify
+## Other Git providers
 
-A Netlify integration is under consideration. If you're interested in branching with Netlify, [join the GitHub discussion](https://github.com/orgs/supabase/discussions/18938).
+There are multiple alternative Git providers under consideration. If you're interested in branching for GitLab, Bitbucket, or some other provider, [join the GitHub discussion](https://github.com/orgs/supabase/discussions/18938).
 
 ## Alternatives to branching
 

apps/docs/content/guides/deployment/database-migrations.mdx

@@ -135,7 +135,11 @@ supabase migration up
 
 Finally, you should see the `department` column added to your `employees` table in the local Dashboard.
 
-View the [complete code](https://github.com/supabase/supabase/tree/master/examples/database/employees) for this example.
+<Admonition type="info">
+
+View the [complete code](https://github.com/supabase/supabase/tree/master/examples/database/employees) for this example on GitHub.
+
+</Admonition>
 
 ### Seeding data
 
@@ -175,7 +179,7 @@ values
 
     <StepHikeCompact.Code>
 
-```bash
+```bash Terminal
 supabase db reset
 ```
 
@@ -190,25 +194,67 @@ You should now see the `employees` table, along with your seed data in the Dashb
 
 This workflow is great if you know SQL and are comfortable creating tables and columns. If not, you can still use the Dashboard to create tables and columns, and then use the CLI to diff your changes and create migrations.
 
-Create a new table called `cities`, with columns `id`, `name` and `population`. To see the corresponding SQL for this, you can use the `supabase db diff --schema public` command. This will show you the SQL that will be run to create the table and columns. The output of `supabase db diff` will look something like this:
+<StepHikeCompact>
+
+  <StepHikeCompact.Step step={1}>
+    <StepHikeCompact.Details title="Create your table from the Dashboard">
+      Create a new table called `cities`, with columns `id`, `name` and `population`.
 
+      Then generate a [schema diff](/docs/reference/cli/supabase-db-diff).
+    </StepHikeCompact.Details>
+
+    <StepHikeCompact.Code>
+
+```bash Terminal
+supabase db diff -f create_cities_table
 ```
-Diffing schemas: public
-Finished supabase db diff on branch main.
 
+    </StepHikeCompact.Code>
+
+  </StepHikeCompact.Step>
+</StepHikeCompact>
+
+<StepHikeCompact>
+
+  <StepHikeCompact.Step step={2}>
+    <StepHikeCompact.Details title="Add schema diff as a migration">
+      A new migration file is created for you.
+
+      Alternately, you can copy the table definitions directly from the Table Editor.
+    </StepHikeCompact.Details>
+
+    <StepHikeCompact.Code>
+
+```sql supabase/migrations/<timestamp>_create_cities_table.sql
 create table "public"."cities" (
   "id" bigint primary key generated always as identity,
   "name" text,
   "population" bigint
 );
-
 ```
 
-Alternately, you can view your table definitions directly from the Table Editor:
+    </StepHikeCompact.Code>
 
-![SQL Definition](/docs/img/guides/cli/sql-definitions.png)
+  </StepHikeCompact.Step>
+</StepHikeCompact>
+
+<StepHikeCompact>
+
+  <StepHikeCompact.Step step={3}>
+    <StepHikeCompact.Details title="Test your migration">
+      Test your new migration file by resetting your local database.
+    </StepHikeCompact.Details>
 
-You can then copy this SQL into a new migration file, and run `supabase db reset` to apply the changes.
+    <StepHikeCompact.Code>
+
+```bash Terminal
+supabase db reset
+```
+
+    </StepHikeCompact.Code>
+
+  </StepHikeCompact.Step>
+</StepHikeCompact>
 
 The last step is deploying these changes to a live Supabase project.
 
@@ -222,7 +268,7 @@ Head over to [Supabase](https://supabase.com/dashboard) and create a new project
 
   <StepHikeCompact.Step step={1}>
     <StepHikeCompact.Details title="Log in to the Supabase CLI">
-      [Login](/docs/reference/cli/usage#supabase-login) to the Supabase CLI using an auto-generated Personal Access Token.
+      [Login](/docs/reference/cli/supabase-login) to the Supabase CLI using an auto-generated Personal Access Token.
     </StepHikeCompact.Details>
 
     <StepHikeCompact.Code>
@@ -240,7 +286,7 @@ supabase login
 
   <StepHikeCompact.Step step={2}>
     <StepHikeCompact.Details title="Link your project">
-      [Link](/docs/reference/cli/usage#supabase-link) to your remote project by selecting from the on-screen prompt.
+      [Link](/docs/reference/cli/supabase-link) to your remote project by selecting from the on-screen prompt.
     </StepHikeCompact.Details>
 
     <StepHikeCompact.Code>
@@ -258,7 +304,7 @@ supabase link
 
   <StepHikeCompact.Step step={3}>
     <StepHikeCompact.Details title="Deploy database changes">
-      [Push](/docs/reference/cli/usage#supabase-db-push) your migrations to the remote database.
+      [Push](/docs/reference/cli/supabase-db-push) your migrations to the remote database.
     </StepHikeCompact.Details>
 
     <StepHikeCompact.Code>

apps/docs/content/guides/platform/backups.mdx

@@ -135,6 +135,41 @@ A date and time picker will be provided upon pressing the `Start a restore` butt
 
 After locking in the desired point in time to recover to, The Dashboard will then prompt for a review and confirmation before proceeding with the restoration. The project will be inaccessible following this. As such, do ensure to allot for downtime beforehand. This is dependent on the size of the database. The larger it is, the longer the downtime will be. Once the confirmation has been given, the latest physical backup available is downloaded to the project and the database is partially restored. WAL files generated after this physical backup up to the specified point-in-time are then downloaded. The underlying records of transactions in these files are replayed against the database to complete the restoration. The Dashboard will display a notification once the restoration completes.
 
+## Restore to a new project
+
+Supabase provides a convenient way to restore data from an existing project into a completely new one. Whether you're using physical backups or Point-in-Time recovery (PITR), this feature allows you to duplicate project data with ease, perform testing safely, or recover data for analysis. Access to this feature is exclusive to users on paid plans and requires that physical backups are enabled for the source project.
+
+<Admonition type="note">
+
+PITR is an additional add-on available for organizations on a paid plan with physical backups enabled.
+
+</Admonition>
+
+To begin, switch to the source project—the project containing the data you wish to restore—and go to the [database backups](https://supabase.com/dashboard/project/_/database/backups/restore-to-new-project) page. Select the **Restore to a New Project** tab.
+
+A list of available backups is displayed. Select the backup you want to use and click the "Restore" button. For projects with PITR enabled, use the date and time selector to specify the exact point in time from which you wish to restore data.
+
+Once you’ve made your choice, Supabase takes care of the rest. A new project is automatically created, replicating key configurations from the original, including the compute instance size, disk attributes, SSL enforcement settings, and network restrictions. The data will remain in the same region as the source project to ensure compliance with data residency requirements. The entire process is fully automated.
+
+<Admonition type="note">
+
+The time required to complete the restoration can vary depending largely on the volume of data involved. If you have a large amount of data you can opt for higher performing disk attributes on the source project _before_ starting a clone operation. These disk attributes will be replicated to the new project. This incurs additional costs which will be displayed before starting.
+
+</Admonition>
+
+There are a few important restrictions to be aware of with the "Restore to a New Project" process:
+
+- Projects that are created through the restoration process cannot themselves be used as a source for further clones at this time.
+- The feature is only accessible to paid plan users with physical backups enabled, ensuring that the necessary resources and infrastructure are available for the restore process.
+
+Before starting the restoration, you’ll be presented with an overview of the costs associated with creating the new project. The new project will incur additional monthly expenses based on the mirrored resources from the source project. It’s important to review these costs carefully before proceeding.
+
+Once the restoration is complete, the new project will be available in your dashboard and will include all data, tables, schemas, and selected settings from the chosen backup source. It is recommended to thoroughly review the new project and perform any necessary tests to ensure everything has been restored as expected.
+
+New projects are completely independent of their source, and as such can be modified and used as desired.
+
+Restoring to a new project is an excellent way to manage environments more effectively. You can use this feature to create staging environments for testing, experiment with changes without risk to production data, or swiftly recover from unexpected data loss scenarios.
+
 ## Troubleshooting
 
 ### Logical backups

apps/studio/components/interfaces/DataWarehouse/WarehouseCollectionDetail.tsx

@@ -220,10 +220,6 @@ order by timestamp desc limit ${filters.limit} offset ${filters.offset}
               />
             </form>
             <div className="flex items-center gap-2">
-              <Button asChild type={'text'}>
-                <Link href={`/project/${projectRef}/settings/warehouse`}>Access tokens</Link>
-              </Button>
-
               <Tooltip>
                 <TooltipTrigger asChild>
                   <Button asChild className="px-1.5" type="outline" icon={<Terminal />}>

apps/studio/components/layouts/LogsLayout/LogsSidebarMenuV2.tsx

@@ -242,14 +242,6 @@ export function LogsSidebarMenuV2() {
         >
           Templates
         </InnerSideMenuItem>
-        <InnerSideMenuItem
-          title="Settings"
-          isActive={isActive(`/project/${ref}/settings/warehouse`)}
-          href={`/project/${ref}/settings/warehouse`}
-        >
-          Settings
-          <ArrowUpRight strokeWidth={1} className="h-4 w-4" />
-        </InnerSideMenuItem>
       </div>
       <Separator className="my-4" />
 

apps/studio/data/analytics/warehouse-access-tokens-create-mutation.ts

@@ -8,6 +8,10 @@ type WarehouseAccessTokenCreateVariables = {
   ref: string
   description: string
 }
+
+/**
+ * This will be deprecated or rewritten in favor of the new project API keys
+ */
 async function createWarehouseAccessToken({
   ref,
   description,

apps/studio/data/analytics/warehouse-access-tokens-delete-mutation.ts

@@ -8,7 +8,9 @@ export type DeleteAccessTokenArgs = {
   projectRef: string
   token: string
 }
-
+/**
+ * This will be deprecated or rewritten in favor of the new project API keys
+ */
 export async function deleteWarehouseAccessToken({ projectRef, token }: DeleteAccessTokenArgs) {
   const { data, error } = await del(
     '/platform/projects/{ref}/analytics/warehouse/access-tokens/{token}',

apps/studio/data/analytics/warehouse-access-tokens-query.ts

@@ -30,7 +30,9 @@ export async function getWarehouseAccessTokens(
 
 export type WarehouseAccessTokensData = Awaited<ReturnType<typeof getWarehouseAccessTokens>>
 export type WarehouseAccessTokensError = ResponseError
-
+/**
+ * This will be deprecated or rewritten in favor of the new project API keys
+ */
 export const useWarehouseAccessTokensQuery = <TData = WarehouseAccessTokensData>(
   { projectRef }: WarehouseAccessTokensVariables,
   {

apps/www/_blog/2024-09-30-lw12-hackathon-winners.mdx

@@ -1,5 +1,5 @@
 ---
-title: 'Supabase Launch Week 12 Hackathon'
+title: 'Supabase Launch Week 12 Hackathon Winners'
 description: Announcing the winners of the Supabase Launch Week 12 Hackathon.
 author: tyler_shukert
 image: lw12/hackathon-winners/thumbnail.png