diff --git a/www/_blog/2021-12-01-realtime-row-level-security-in-postgresql.mdx b/www/_blog/2021-12-01-realtime-row-level-security-in-postgresql.mdx
index 1f0cceab96a..8095ae625a9 100644
--- a/www/_blog/2021-12-01-realtime-row-level-security-in-postgresql.mdx
+++ b/www/_blog/2021-12-01-realtime-row-level-security-in-postgresql.mdx
@@ -59,7 +59,7 @@ An RLS policy is a snippet of SQL filtering which users have the authority to cr
 
 For example, the following policy would allow users to select their own rows in a todos table:
 
-```sql
+```sql hideCopy
 create policy todo_select_policy 
     on todos for select 
     using ( auth.uid() = user_id );
@@ -67,7 +67,7 @@ create policy todo_select_policy
 
 which is equivalent to adding
 
-```sql
+```sql hideCopy
 select *
 from todos
 where auth.uid() = todos.user_id; -- Policy is implicitly added.
@@ -115,14 +115,14 @@ To maximize throughput, the query used to evaluate if a row is visible to a subs
 
 For example:
 
-```sql
+```sql hideCopy
 select exists(select 1 from some_table where id = 806);
 ```
 
 When more than one subscriber exists, the query is wrapped in a [prepared statement](https://www.postgresql.org/docs/13/sql-prepare.html) to remove the cost of the PostgreSQL 
 query planner on subsequent calls. The query planner time is frequently 2-3x execution time for simple queries, so this immediately multiplies throughput in the most common cases!
 
-```sql
+```sql hideCopy
 "Planning Time: 0.099 ms"
 "Execution Time: 0.051 ms"
 ```