Picture a mid-sized Indian fintech deploying its first AI-powered credit decisioning system. The model performs well in testing. The engineering team is confident. Then it goes to production.
Within days, the symptoms appear. Latency spikes. An agent that reads customer history to inform a lending decision occasionally acts on data that is milliseconds out of date, not because the model is wrong, but because the database underneath it was designed for a different era. A human checking a balance can tolerate a slight delay. An AI agent making a real-time decision cannot.
This scenario is playing out quietly across Indian enterprises right now. The AI works. The infrastructure underneath it does not.
One model, many workloads
AI systems do not introduce one new workload. They introduce several, simultaneously, and in patterns that cannot be predicted at design time. A single production AI application might require consistent transactional writes to manage agent state, low-latency retrieval across structured records, semantic search over embeddings, and concurrent analytical queries, all against the same data, at the same time.
Vector search handles one of those. A purpose-built vector database handles one of those. The rest of the system still needs somewhere to live.
Legacy architectures were built on the opposite assumption: that workloads could be separated and optimized independently. Transactional systems handled writes. Analytical systems handled reporting. Each stayed in its lane. AI systems refuse to stay in lanes. And infrastructure built for the old model breaks under the pressure of the new one.
The problem deepens with agentic AI. Conventional databases were designed around predictable query shapes. An agent managing a logistics workflow might read context, write state mid-task, trigger analytical lookups, and discard intermediate data, all within a single reasoning loop, repeated across thousands of concurrent agents. In these environments, humans are no longer the primary database users. Agents are. Elasticity under unknown query patterns is not a tuning problem. It is an architectural one.
The consistency trap
There is a durable misconception that AI workloads are predominantly read-heavy systems that can tolerate relaxed consistency guarantees. This mischaracterizes how production AI systems actually manage state.
The moment an AI system is trusted to act, not just recommend, it inherits the consistency requirements of the business processes it is executing. An agent approving a credit decision needs the same transactional guarantees as a core banking system. Vector-first architectures were not built with this in mind, which is why enterprises end up bolting a relational system for state management alongside their retrieval layer and spend engineering cycles keeping them synchronized.
This is the gap that distributed SQL databases like TiDB were designed to close running transactional, analytical, and retrieval workloads natively against the same data layer, without the synchronization overhead of stitching separate systems together.
Delhivery, one of India’s largest logistics platforms, hit this wall at scale. Their existing setup was buckling at 3,000 writes per second, with 5 TB of data bloating to 30 TB in storage and a $100,000 monthly database bill. After moving to TiDB, they exceeded 10,000 transactions per second, improved query performance by 15-20%, and cut costs substantially on a single unified architecture.
India cannot afford to get this wrong
Digital-native Indian companies move from inception to tens of millions of users in timeframes that would be considered aggressive in more mature markets. There is rarely runway to re-architect a database layer after the fact. The decisions made at Series A compound through Series C and beyond.
India’s digital economy is projected to reach one trillion dollars by 2030. The enterprises leading that number are making infrastructure decisions right now, before the scale pressure arrives. The AI narrative here tends to center on models: which foundation model, which benchmark. These are legitimate questions, but second-order ones.
The first-order question is whether the data infrastructure underneath the model can support the access patterns the AI system will generate. A vector database answers a narrow slice of that question. The rest, consistency, scale, workload convergence, agent elasticity, still needs an answer.
In this new era, infrastructure, not the model, and not any single database category, will define competitive advantage.
That is the conversation India’s enterprise leaders should be having.
Authored by Siddon Tang, Chief AI Officer, TiDB