High time for relational databases to start thinking?

The relational databases are gold mines. They have all the data and relationships. The volume and velocity of the data that it ingests and the rate of retrieval every second tells a lot about the business. It's like the heartbeat of the business. For instance, your DB size has grown by 10% in the last 7 days. It could mean your business had significant growth due to some GTMs. It could also mean your DBA should have a strategy in place to work on partitioning a few customers to not let their dashboards slow down. On the contrary, it could also mean your engineer (or coding agent) made a mistake that is simply bloating the DB and ingesting all unwanted stuff.

A little bit about myself before delving into the 'thinking…' aspects of the database.

I was an MTS (Member of Technical Staff) at Oracle, Query Engine Team. It was one of the founding teams at Oracle, I had a great opportunity and privilege to own and edit the C code files written by Bruce Scott (famously known for his scott/tiger default login/pass to Oracle DB).

Fast forward to today, I am running a YC company, Stayflexi - a hotel technology platform, empowering over 5000+ hotels worldwide, processing tera bytes of data everyday.

Building database engines and then actually using them has been a rewarding experience. I've always had an inkling about the true superpowers of RDBMS. The optimizer is the intelligent core of relational databases, yet it fails to think from a business perspective—and innovation in these optimizers effectively stalled once the cloud era began. What's really driving revenue for Snowflake, Databricks, and similar cloud-based databases? It's not how efficiently your queries run; it's about how bad they are. The worst query execution plans demand more compute and resources, which just translates to more $$$ for these companies.

The database bloat…

At Stayflexi, we experienced massive database bloat after adopting coding agents like Claude Code and Cursor. The number of tables in our schema tripled within a couple of months of adopting these agents.

This happened largely because there is no cohesive understanding of the schema. There was no one to reason: "Hey, for this feature, you could actually reuse these tables, or you may not need them at all. You just need one or two tables, or perhaps you need to denormalize these existing tables to achieve your goal."

Essentially, that DBA-level reasoning was missing. Whatever the developer requests goes to the coding agent, which simply churns out a bunch of new tables and implements the feature. This adds another dimension to the problem from a product development perspective: schema and database bloat, costing us 3x more spend in the matter of 2 months.

The fuckup moment…

Amidst this bloat, we were hit by a security breach: PII data was leaking from a legacy endpoint no one recognized or used. As teams traded blame, I realized the issue was systemic. Whether by an app or a user, access is access. If you can't monitor every door to your house, you're vulnerable. This isn't just a security oversight, it's a database failure. A database should inherently monitor access patterns, distinguishing between standard operations and an active breach.

Conventional wisdom says to hire a DBA, but my database background told me otherwise. This wasn't just a staffing issue, it was a systemic one. I started asking deeper questions: What if a database could hold context? What if it could distinguish between normal and abnormal patterns? What if it could reason through business logic, user behavior, and actual usage? That's what sparked the idea.

Deepsql Inception …

I observed how developers interacted with our databases via coding agents and realized their knowledge was trapped in personal Markdown files. Experienced developers maintained strong, custom documentation within Claude, while others lacked this understanding, leading to inconsistent schema interpretation. Lacking a cohesive, organization-wide understanding was a core problem. To address it, I built a "brain"—a context layer atop our MySQL database. It maps our schema and incorporates slow query logs and application code, allowing the system to deeply understand entity relationships, workflows, and column dependencies.

Applying DeepSQL as a context layer to our production database immediately revealed severe inefficiencies—for example, a recurring date-conversion pattern was preventing index usage across 23 BI queries, costing us $4,500/month in wasted compute. We also moved user access controls to the DeepSQL layer. This allowed us to define access rules in natural language, ensuring that restricted users could never access sensitive PII data, regardless of which coding agent they used.

There is a temporary relief for now from my company's perspective, but I'm still on the quest to understand what a thinking database should look like…

Thinking databases?

A 'self-driving' database should do more than just store and retrieve data—it should understand its heartbeat, predict shifts, and warn you before trouble hits. If a database could do that, it wouldn't just be a storage engine; it would be an Oracle—a god in a box.

At the surface level, I tested this theory with DeepSQL by analyzing customer churn. By tracking product usage patterns, data velocity, and shifting bell curves already embedded in our context layer, I asked the system to predict churn for the next two months. The results were stunning: 70% of its predictions were spot on. Maybe this is a straightforward experiment, but there could be some deeper insights buried. I don't know what I don't know…

We're all blind to the meta-signals buried in our data. As an executive, I'm often forced to fly by instinct, missing shifts in customer traction or product health. My engineers are just as handicapped—reactively chasing fires or surprise cloud bills instead of anticipating them.

We're stuck in a reactive loop because our databases are just storage. What if they were intelligent? Imagine a database that doesn't just hold your rows, but flags an impending 30% cost spike or shifts in product usage as they happen.

Is this the next evolution of the RDBMS? DeepSQL is my attempt to build a brain for the database, but it's just the beginning. We've spent decades perfecting how we store data—now, is it time to teach that database how to think …?