diff --git a/apps/docs/content/guides/database/postgres/row-level-security.mdx b/apps/docs/content/guides/database/postgres/row-level-security.mdx
index 683fc7e1e5f..d2090a1ffb7 100644
--- a/apps/docs/content/guides/database/postgres/row-level-security.mdx
+++ b/apps/docs/content/guides/database/postgres/row-level-security.mdx
@@ -9,16 +9,25 @@ When you need granular authorization rules, nothing beats Postgres's [Row Level
 
 ## Row Level Security in Supabase
 
+<Admonition type="danger">
+
+Supabase allows convenient and secure data access from the browser, as long as you enable RLS.
+
+RLS _must_ always be enabled on any tables stored in an exposed schema. By default, this is the `public` schema.
+
+RLS is enabled by default on tables created with the Table Editor in the dashboard. If you create one in raw SQL or with the SQL editor, remember to enable RLS yourself:
+
+```sql
+alter table <schema_name>.<table_name>
+enable row level security;
+```
+
+</Admonition>
+
 RLS is incredibly powerful and flexible, allowing you to write complex SQL rules that fit your unique business needs. RLS can be [combined with Supabase Auth](/docs/guides/database/postgres/row-level-security) for end-to-end user security from the browser to the database.
 
 RLS is a Postgres primitive and can provide "[defense in depth](<https://en.wikipedia.org/wiki/Defense_in_depth_(computing)>)" to protect your data from malicious actors even when accessed through third-party tooling.
 
-<Admonition type="note">
-
-You should _always_ enable RLS on tables created in a public schema. This is done for you when you create a table with the Table Editor. If you create one in raw SQL or with the SQL Editor, remember to enable RLS yourself.
-
-</Admonition>
-
 ## Policies
 
 [Policies](https://www.postgresql.org/docs/current/sql-createpolicy.html) are Postgres's rule engine. Policies are easy to understand once you get the hang of them. Each policy is attached to a table, and the policy is executed every time a table is accessed.