From e967622d136596cc7bc0cac5fac6ecb7dc2d6c92 Mon Sep 17 00:00:00 2001
From: egor-romanov <egor.romanov@gmail.com>
Date: Thu, 13 Jul 2023 15:29:29 +0300
Subject: [PATCH] add missing chart

---
 apps/www/_blog/2023-07-13-pgvector-performance.mdx | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/apps/www/_blog/2023-07-13-pgvector-performance.mdx b/apps/www/_blog/2023-07-13-pgvector-performance.mdx
index dea6e8fc316..688764ce8ab 100644
--- a/apps/www/_blog/2023-07-13-pgvector-performance.mdx
+++ b/apps/www/_blog/2023-07-13-pgvector-performance.mdx
@@ -154,6 +154,19 @@ Again, it is NOT our goal to prove that pgvector is better than Qdrant for runni
 
 </div>
 
+<div>
+  <img
+    alt="multi database"
+    className="dark:hidden"
+    src="/images/blog/2023-07-13-pgvector-performance/pgvector-8xl--light.png"
+  />
+  <img
+    alt="multi database"
+    className="hidden dark:block"
+    src="/images/blog/2023-07-13-pgvector-performance/pgvector-8xl--dark.png"
+  />
+</div>
+
 Although more compute is required to match Qdrant's precision and RPS levels concurrently, this is still a satisfying outcome. It means that it's not a _necessity_ to use another vector database - if you want to lower your operational complexity, just increase your Postgres size.
 
 ### Final results: pgvector performance