AI Runs on Real-Time Data: Is Your Infrastructure Ready?
Executive Summary
In this webinar, Tom O’Neil, VP of Product at Silk, and Kellen Gorman, AI Advisor at Silk and Advocate & Engineer at Redgate, explore how the rise of AI and agentic systems is reshaping data infrastructure. They examine why relational databases remain essential to AI workloads, how to prevent AI from overwhelming production systems, and what best practices organizations can adopt to deliver real-time data safely and efficiently.
Topics include data governance, performance tuning, vector storage, AI-induced database strain, and practical steps for preparing infrastructure for AI-driven demands.
Key Takeaways
⚙️ Relational Databases Still Matter: Most valuable enterprise data remains in traditional relational systems like Oracle, SQL Server, and Postgres — vital for AI training and inference.
🚦 Manage AI Load Carefully: Direct AI access to production systems risks performance degradation; using snapshots or database copies mitigates this.
🔐 Shadow AI = Real Risk: Unauthorized AI tools can lead to data leakage; organizations must establish governance and approved AI usage policies.
💾 Balance Structure and Speed: ETL alone isn’t sufficient for real-time AI needs — consider low-latency copies, intelligent caching, and high-performance storage.
🧠 Use the Right Tools: Not all data needs to be vectorized. Apply vector storage only where semantic search or embedding similarity is truly required.
[00:00:00] Introduction
Tom O’Neil (Silk):
Welcome, everyone, to today’s webinar — “AI Runs on Real-Time Data: Is Your Infrastructure Ready?”
I’m Tom O’Neil, VP of Product at Silk, and joining me today is Kellen Gorman from Redgate.
Kellen Gorman (Redgate / Silk):
Thanks, Tom. I’m an Advocate and Engineer at Redgate and also serve as an AI Advisor with Silk. I’ve been in the database technology space for almost 30 years and, more recently, deeply involved in the AI world. Happy to be here!
Tom:
Fantastic, Kellen. In the next 30 minutes, we’ll unpack what breaks when generative AI systems hit your systems of record — and how to deliver live data to AI without melting your production systems or skyrocketing your cloud bill.
[00:01:00] Why AI Needs Relational Data
Tom:
Why are AI systems so intent on accessing relational databases?
Kellen:
Because AI is only as good as the data it consumes — and relational databases hold the richest, most structured, most valuable data. Whether it’s Oracle, SQL Server, DB2, or Sybase, those transactional systems contain decades of historical and real-time information.
Even though organizations are storing unstructured data in Parquet files or PDFs, structured data remains the backbone of analytics, trends, and insights. To train and operate effectively, AI systems need access to that.
[00:02:00] What Does “Real-Time” Really Mean?
Tom:
We hear “real-time data” all the time. But in practical terms, what does “real-time” mean in this context?
Kellen:
That depends on the workload. For analytical systems (OLAP), real time might mean minutes or hours — optimizing long-running batch jobs. For transactional systems (OLTP), “real time” means microseconds or milliseconds.
When AI demands real-time data from transactional systems, it introduces constant, concurrent changes — something traditional databases were never designed to handle at this scale.
[00:04:00] Emerging AI Use Cases
Tom:
We’re seeing AI driving use cases like fraud detection, real-time pricing, predictive healthcare, and live marketing analytics — all of which hit relational systems.
Kellen:
Exactly. Every organization now has an “AI objective.” But many didn’t understand what that meant at first — they started connecting AI tools directly to production databases. This is dangerous. It’s like allowing BI systems to hit live OLTP systems without an intermediary.
We used to build data warehouses and aggregated reporting copies to avoid overloading production. We need that same thinking again with AI — to protect “golden copies” of data.
[00:07:00] Controlling Where AI Connects
Tom:
If AI workflows are accessing systems through APIs or applications, how can teams control where those queries go — ideally steering them to copies instead of production?
Kellen:
There are tools for that — like Zscaler and Microsoft Defender — which can block unauthorized API calls or unapproved AI tools.
Also, governance and education are critical. Employees often use “shadow AI” (like free ChatGPT) without realizing they’re uploading confidential data. Organizations must enforce approved AI usage policies to avoid breaches.
[00:09:00] Data Governance and Shadow AI
Kellen:
Let’s be clear — if someone says “AI isn’t happening at our company,” they’re wrong. Every product today embeds AI somewhere.
The risk is data leakage. People copy data into Excel and upload it into AI tools, bypassing security altogether. The solution is to set up governance and automated defenses — products that can detect, block, or sanitize unauthorized AI interactions.
Tom:
So, it’s not about stopping AI — it’s about enabling it safely and intelligently.
[00:12:00] Recognizing AI-Induced Database Strain
Tom:
If AI starts hitting production systems uncontrollably, what would DBAs notice first — locking? IOPS? CPU spikes?
Kellen:
All of the above. AI introduces concurrent workloads that drive high I/O and memory pressure, often transforming a CPU-bound system into an I/O-heavy one.
This changes tuning priorities. AI-driven workloads stress relational systems in ways traditional applications rarely did.
[00:14:00] Choosing the Right Database Architecture
Tom:
If you were designing a database today to handle transactional workloads and AI access, what would you choose?
Kellen:
I’d go with PostgreSQL. It offers flexibility, great concurrency via the write-ahead log (WAL), and freedom from costly enterprise licensing.
However, for AI, you’ll still need infrastructure-level performance — not just managed cloud services. Many organizations underestimate the I/O throughput required for AI-scale operations.
[00:16:00] Coping with AI Query Spikes
Tom:
AI queries can be unpredictable and often poorly written. How can DBAs tune or protect systems against them?
Kellen:
First — never allow AI or analytics platforms to update production data. Keep your golden source immutable.
Second — distribute workloads intelligently. Use clustered databases, replication, or Silk-powered zero-footprint copies to handle load spikes.
And finally — store only what makes sense as vectors. Don’t over-vectorize everything; use the right tool for the job.
[00:19:00] Understanding Vector Storage
Tom:
Can you explain, in simple terms, what vectors or embeddings are, and how they fit into databases?
Kellen:
Sure. Vectors are numeric representations of data that enable similarity search — for example, finding related documents or matching user queries semantically.
But not all data belongs in vector form. Employee names, departments, or structured relational data should stay relational. Use vectors only for unstructured, context-based data — otherwise, you’re adding unnecessary complexity.
[00:21:00] The Danger of AI Updating Databases
Tom:
You mentioned AI modifying data earlier — that sounds terrifying.
Kellen:
It is. Imagine an agentic AI that not only reads from your database but also writes back, influenced by prompts or hallucinations. A prompt injection could poison your production data. That’s a nightmare scenario.
Keep AI access read-only, always. Your “golden copy” should never be editable by automated systems.
[00:22:00] The Explosion of Data Copies
Tom:
We’re seeing enterprises creating more and more database copies for AI workloads — sometimes dozens. Have you seen that too?
Kellen:
Absolutely. I’ve seen companies maintaining over 100 copies of their production data for different AI experiments. It’s costly and risky.
But with technologies like Silk’s Echo, you can create instant, space-efficient clones — reducing both storage footprint and cost while maintaining real-time fidelity.
[00:24:00] Audience Q&A Highlights
Tom:
We’ve had a few questions come in. Let’s take some.
Q: Can chatbots query production systems safely without causing locks?
Kellen: Yes — by using read-write snapshots or materialized views. Regularly refreshed copies provide up-to-date data without hitting production directly.
Q: For Oracle databases, how can we limit AI query rates?
Kellen: Use Oracle Resource Manager to throttle CPU, memory, and session limits per user. It’s robust and can also restrict data volume returned per query.
Q: How do we keep AI data copies fresh for fraud detection?
Kellen: Combine snapshotting with log shipping or tools like GoldenGate to incrementally update copies — maintaining near-real-time sync without impacting performance.
[00:27:00] Closing Remarks
Tom:
Kellen, this has been an enlightening conversation. Thank you for your insight and expertise.
Kellen:
Always a pleasure, Tom. These discussions help teams think about AI realistically — with governance and performance in mind.
Tom:
For everyone watching, the replay and resources will be emailed shortly. If you’d like a deeper dive into your AI infrastructure or data strategy, book a 30-minute consultation with Silk.
Thank you all for joining us — see you next time.
