diff --git a/content/700-optimize/300-recordings.mdx b/content/700-optimize/300-recordings.mdx
index 847a1b893b..eef4110a02 100644
--- a/content/700-optimize/300-recordings.mdx
+++ b/content/700-optimize/300-recordings.mdx
@@ -42,6 +42,7 @@ When a recording session ends, Optimize generates recommendations such as:
 - [Repeated query](/optimize/recommendations/repeated-query)
 - [Overfetching](/optimize/recommendations/select-returning)
 - [Using `@db.Money`](/optimize/recommendations/avoid-db-money)
+- [Using `@db.Char(n)`](/optimize/recommendations/avoid-char)
 - [Using `@db.VarChar(n)`](/optimize/recommendations/avoid-varchar)
 - [Using `timestamp(0)` or `timestamptz(0)`](/optimize/recommendations/avoid-timestamp-timestampz-0)
 
diff --git a/content/700-optimize/400-recommendations/700-avoid-char.mdx b/content/700-optimize/400-recommendations/700-avoid-char.mdx
new file mode 100644
index 0000000000..1870cb799d
--- /dev/null
+++ b/content/700-optimize/400-recommendations/700-avoid-char.mdx
@@ -0,0 +1,21 @@
+---
+title: 'Using @db.Char(n)'
+metaTitle: 'Optimize Recommendations: Avoid usage of `@db.Char(n)`'
+metaDescription: "Learn about the recommendation provided by Optimize for using `@db.Char(n)` native type."
+---
+
+Optimize provides recommendations to help you identify and resolve performance issues caused by the use of `@db.Char(n)` type in PostgreSQL.
+
+In the following example, the `@db.Char(n)` native type has been used within the `Item` model on the `name` field:
+
+```prisma
+model Item {
+  // ...
+  name String @db.Char(1)
+  // ...
+}
+```
+
+### Why this is a problem
+
+The `@db.Char(n)` type enforces a fixed length of `n`, which can cause unexpected issues in production if not properly managed by the application. In PostgreSQL, `char(n)` pads shorter values with spaces, leading to problems during comparisons and other operations. Unlike some databases that optimize `char(n)`, PostgreSQL does not offer such optimizations, making careful handling essential.