From 405463eaf7914e57c269bb67f1063f4b547ebf1a Mon Sep 17 00:00:00 2001
From: Will Stamatis <114952643+wlsdbt@users.noreply.github.com>
Date: Tue, 31 Oct 2023 13:36:56 -0400
Subject: [PATCH] Update clone.md

included Kshitij's article on dbt clone vs. deferral.
---
 website/docs/reference/commands/clone.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/docs/reference/commands/clone.md b/website/docs/reference/commands/clone.md
index ea3e570447d..9852ce84c17 100644
--- a/website/docs/reference/commands/clone.md
+++ b/website/docs/reference/commands/clone.md
@@ -37,3 +37,5 @@ Unlike deferral, `dbt clone` requires some compute and creation of additional ob
 For example, by creating actual data warehouse objects, `dbt clone` allows you to test out your code changes on downstream dependencies _outside of dbt_ (such as a BI tool). 
 
 As another example, you could `clone` your modified incremental models as the first step of your dbt Cloud CI job to prevent costly `full-refresh` builds for warehouses that support zero-copy cloning.
+
+Check out [this Developer blog post](https://docs.getdbt.com/blog/to-defer-or-to-clone) for more details on best practices when to use `dbt clone` vs. deferral.