Inside the Lab: Testing AI-Powered Vector Extensions in Databases

Webinar Transcript

Topic: How Vector Indexes Are Changing the Game for AI and Relational Databases
Speakers:

Host: [Silk Team Member – unspecified in transcript]

Guest: Tanel Poder, Database Performance Expert and Author of CatBench

Summary

In this technical “Inside the Lab” session, database performance expert Tanel Poder joins Silk to share insights from his research into AI-powered vector extensions in traditional relational databases.

The conversation explores how modern databases like PostgreSQL, Oracle, and SQL Server are evolving to support semantic search, vector indexing, and generative AI use cases — all without leaving the comfort of the relational data model.

Tanel also unveils his open-source CatBench benchmarking tool, used to measure vector performance in real-world scenarios such as recommendation engines and fraud detection. The discussion concludes with a deep dive into performance results from Silk’s platform, how Google AlloyDB compares to vanilla PostgreSQL, and why the future of AI in relational systems depends on performance, reliability, and security.

Key Takeaways

Vector extensions enable semantic and similarity-based queries directly inside relational databases.

They make it possible to add AI-like search and recommendation capabilities to existing systems without re-platforming.

Real-world applications include product recommendations, fraud detection, and customer support summarization.

Performance, security, and uptime remain critical challenges for production AI workloads.

Silk’s high-throughput storage layer significantly boosts vector performance and scalability in PostgreSQL and AlloyDB tests.

Transcript
[00:00–01:00] Introduction

Host:
Hi everyone, and welcome to Inside the Lab. Today we’re discussing AI-powered vector extensions in databases — what they are, how they work, and why they matter.
I’m joined by Tanel Poder, an expert in database performance and AI integration. Tanel’s been exploring how relational databases are adding semantic search and AI capabilities.

Let’s dive right in. Tanel, what exactly are vector extensions, and how do they bring innovation to traditional databases?

[01:00–02:00] What Are Vector Extensions?

Tanel Poder:
Think back 25 years — search engines could only find exact keywords. If you searched for an alias or a related term, you got nothing. Then along came Google, which used meaning-based search.

The same evolution is happening in databases. Traditional indexes rely on exact matches — product ID 5, a customer’s exact name, etc. With vector indexes, you can now perform fuzzy, open-ended searches that understand similarity and meaning.

It’s like adding a touch of “Google inside your database.” You can describe what you’re looking for in natural terms, and the system can understand and return the right data.

[02:00–04:00] Real-World Applications

Host:
That’s a great analogy. Can you share examples of how vector extensions add innovation in practice?

Tanel:
Absolutely. Generative AI has made it possible to summarize complex, human-meaningful information into vector representations — small numerical summaries of meaning.

For example, you can use vectors to power product recommendations:

Instead of filtering by basic demographics, you can recommend products based on behavioral similarity between customers.

Two users with 80% overlapping purchase histories can influence each other’s recommendations.

You can even use image embeddings — such as photos of products or, in my CatBench project, cat photos — to find visually similar items.

[04:00–07:00] Text Embeddings and Customer Insights

Tanel:
It goes beyond images. Using text embeddings, we can turn millions of customer conversations — sales chats, support requests, feedback logs — into searchable vectors.

Next time a sales rep talks to a customer, the system can summarize five years of history instantly:

“Top five pain points for this customer have been X, Y, and Z.”

That’s a huge leap from scrolling through pages of text. Vectors make this kind of semantic retrieval possible directly inside databases using standard SQL plus AI extensions.

[07:00–09:00] Universal Use Cases Across Industries

Host:
At Silk, we’re seeing adoption across verticals — healthcare, finance, retail. Are vector extensions applicable everywhere relational databases are used?

Tanel:
Exactly. The beauty is that every major database vendor now supports vector indexing and AI APIs — Postgres, Oracle, SQL Server, MySQL.

This democratizes AI for everyone. Ten years ago, machine learning was reserved for hedge funds and research labs. Now, thanks to embeddings and vectors, every business can apply AI to their own structured data — language, images, context — all within familiar systems.

[09:00–12:00] Challenges: Performance, Security, and Reliability

Host:
Whenever we talk AI in production, the same concerns arise — performance, security, and reliability. What’s your take?

Tanel:
Those are the right concerns. Vector support arrived fast, and vendors raced to add APIs for calling AI models like OpenAI directly from databases.

The good news: you don’t need to re-platform. You can stay on your existing relational database — just upgrade to the latest release.

But you must account for:

Increased data access by AI agents

Real-time synchronization to avoid outdated data

Security hardening, since prompt injections could trick AI agents into retrieving restricted information

We’re entering a world where AI agents book tickets or access transactions — so your database must remain fast, accurate, and secure.

[12:00–14:00] Introducing the CatBench Benchmark

Host:
You’ve been testing vector extensions using your own benchmarking tool. Tell us about that.

Tanel:
Yes — I built CatBench, an open-source benchmark to test vector performance across databases. It uses a dataset of about 25,000 cat photos from open competitions and measures vector indexing, search, and aggregation performance.

I combined this with a transactional workload (HammerDB) to simulate real mixed environments — both OLTP and AI queries running together.

The two main CatBench use cases:

Product Recommendation Engine — find top purchases made by “similar cats.”

Fraud Detection — flag mismatched images when a different-looking cat claims the same identity.

[14:00–17:00] Benchmarking Design and Real-World Parallels

Tanel:
These scenarios map easily to real businesses — retail image search, patient records in healthcare, customer identity in finance.

Each use case involves large vector indexes, multi-gigabyte data, and frequent reads. A single vector search might hit thousands of storage blocks, not just a few dozen like traditional indexes.

That’s where Silk’s performance layer makes a major difference — it keeps these searches fast even at scale.

[17:00–20:00] Results: PostgreSQL and AlloyDB on Silk

Host:
You ran these tests on Silk with PostgreSQL and Google AlloyDB. What did you see?

Tanel:
PostgreSQL 17 introduced better multi-block reads and improved full-table scan performance. On Silk in Google Cloud, I achieved:

20 GB/s read throughput and 10 GB/s write throughput at the VM level.

PostgreSQL itself sustained about 5–6 GB/s reads and 4–5 GB/s writes under mixed workloads.

About 17,000 transactions per second (≈800K per minute) on HammerDB.

Then I tested Google AlloyDB Omni, which runs in containers but remains fully Postgres-compatible. AlloyDB achieved 40–50% higher throughput — around 12–14 GB/s reads — showing Google’s I/O path and caching optimizations.

[20:00–23:00] Observations and Lessons Learned

Tanel:
The main takeaway: performance bottlenecks often come from the file system and OS cache, not the hardware.

Silk’s underlying infrastructure eliminated those bottlenecks. Without Silk, I would’ve hit cloud I/O limits long before reaching those speeds.

The same setup on Oracle would easily max out the 20 GB/s hardware ceiling — Postgres just isn’t as direct with disk I/O yet. But we’re getting close.

[23:00–24:30] Production Readiness and Recommendations

Host:
Given your experience, would you recommend using vector search in production systems yet?

Tanel:
Yes — but with caveats.

Always run on the latest database version (e.g., PGVector 0.8 or newer).

Understand your goals — what problem are you solving, and what kind of index fits best?

Test thoroughly with representative workloads and real data volumes.

If you’re already using Postgres, Oracle, or SQL Server, use their native vector capabilities rather than adding a standalone vector DB. That’s where the real business value comes — AI-enhanced applications with minimal risk or disruption.

[24:30–25:00] Closing Remarks

Host:
We’re looking forward to seeing your upcoming results on Oracle and SQL Server once their new vector features are fully available.

Thank you, Tanel, for sharing your insights and for building CatBench — it’s a great tool for anyone exploring AI and database performance.

For those who’d like to learn more, visit silk.us/blog for Tanel’s benchmark data and deeper technical dives.

Tanel:
Thank you! It’s been great to share the journey.