There is a paradox that I have been observing in the industry for several years now. The frontend of fintech looks like the future (instant payments, AI scoring, real-time personalization). And the backend sometimes looks like the past: monolithic databases, manual sharding, ETL pipelines that cannot keep up with the volume of transactions.
While the market is growing moderately. But when real scaling begins, the old infrastructure turns into a growth ceiling. And teams start putting out fires instead of developing a product.
Where the old model breaks down
Traditional relational databases worked well as long as financial products were local, traffic was predictable, and analytics could wait until morning. None of these conditions are met anymore.
The first pain point is unpredictable spikes. A viral referral campaign, market volatility, holiday shopping, where fintech traffic is inherently uneven. Vertical scaling is no help here: either you pay for excess capacity all year round, or you get a system failure at the worst possible moment.
The second is the disconnect between transactions and analytics. Fraud detection, credit scoring, personalization, all of these require real-time solutions. But when OLTP and OLAP are separated into different systems, there is always a delay between the event and the response. In finance, this delay costs money, sometimes literally.
The third is regulatory pressure. GDPR, PSD2, new data protection laws in Asia are infrastructure requirements. Audit trails, encryption, access control, disaster recovery, all of this should be built into the system, not added on top of it.
Distributed SQL as the answer
The concept of distributed SQL is an attempt to get the best of both worlds: the horizontal scalability of NoSQL and the ACID guarantees of traditional relational databases. Without compromises between them.
The key idea is to separate the computation from the storage. Each layer scales independently. New nodes are added without stopping the system. Analytical and transactional queries are routed to different engines within the same platform (no ETL, no synchronization issues, no separate team maintaining the bridge between the two systems).
For fintech, this means concrete things, handling spikes without manual intervention, getting analytics on live data without delay, performing schema migrations without downtime, and meeting regulatory requirements out of the box, rather than through painful refactoring.
Case study: Plaid: How to get rid of sharding and give engineers back their time
Plaid is one of the largest providers of financial data connectivity in the world. Their engineering team faced a classic problem of a mature platform: the hosted MySQL stack could no longer handle the load, schema migrations took weeks, and availability incidents became the norm.
After switching to TiDB, the results were concrete, where operational costs fell by 25% thanks to the elimination of sharding, resource utilization increased 5 times due to elastic scaling, and large table migrations began to take place without any downtime.
But what is more important to me is not the result itself, but what it means strategically. The team returned the engineering time that previously went to support the infrastructure, now goes to the product.
Artem Lyashanov
What is worth taking from this
The choice of a database is rarely perceived as a strategic decision. Usually it is a technical issue that is resolved somewhere at the level of the architectural committee. But in reality it is one of those decisions whose consequences are felt by the entire company and felt for a long time.
A fintech company that is built on an infrastructure that is not designed for its future scale pays a double price: first with operating costs and failures, then with migration at the worst possible moment, when the product is already in production and any stop costs reputation and money.
The right time to think about data infrastructure is not when it is already on fire. But when there is time to choose calmly. — Artem Lyashanov
How we verify our analysis
Our editorial team cross-checks architectural claims against public guidance from NIST and ENISA, compliance requirements such as PSD2 and GDPR, and published engineering case studies. Where figures come from a single vendor source, we say so and avoid presenting them as universal benchmarks.
Our editorial principles are simple: no hype, no unverified numbers, and clear separation between expert opinion and documented facts. Every article is written for engineers, product leaders and finance teams who need decisions they can defend.