Walk into the data centre of almost any established bank, insurer or telco in the region and you will find the same architecture, laid down in strata. At the top, a mobile app rebuilt eighteen months ago, running in containers, deployed by a pipeline, properly monitored. Below it, APIs written by a team that knows what it is doing, and a message broker. Below all of it, holding the numbers that matter, a single large relational database on hardware specified when the CTO was still a programme manager.
There is a standby, of course, in the DR site. It has been failed over twice in planned drills, both on a Sunday, with the application teams watching and a rollback plan printed out. Nobody has ever failed it over because something broke.
Ask the platform team what happens when transaction volume doubles and they will not describe an architecture. They will describe a procurement cycle. Ask when the next schema change can go in and they will name a date three weeks out, in a window starting 11pm on a Saturday.
The application is modern. The database is not. And every constraint the business feels, every delayed launch, every stale report, every uncomfortable conversation about licence renewal, traces back to that one box.
The modernisation arrow that stops at the data layer
On paper, this problem is solved. There is a cloud strategy, a modernisation roadmap with phases, and probably a slide showing the monolith on the left and microservices on the right.
What the slide does not show is that the arrow between them stops at the data layer. Applications get decomposed. Front ends get rebuilt. Integration gets an API gateway. And the database stays where it was, because moving it is the one part of the programme where failure is not recoverable by rolling back a deployment.
So the data layer gets exempted, quietly, without anyone writing it down. The organisation ends up with cloud-native applications on a database architecture designed for a world where you scaled by buying a bigger machine and achieved availability by keeping a second machine warm.
This is not a failure of ambition but a rational response to genuine risk. The database holds the authoritative record: the ledger in a bank, the policy master in an insurer, the subscriber and billing data in a telco. Nobody gets promoted for touching it, and everybody understands what happens if it goes wrong.
But the exemption has a compounding cost, and it is now coming due in four directions at once. Regulators across the region are tightening expectations on where data sits and how quickly you can prove recovery. Business leadership expects 24×7 service in markets where digital has become the primary channel. Finance is looking hard at per-core licensing that grows every time you add capacity. And the AI and analytics agenda, which every board is now asking about, needs current data that the current architecture structurally cannot supply.
The data layer is where the risk, the cost and the delay actually live. Everything above it has been optimised. The bottleneck moved, and the programme did not follow it.
Where the data layer holds everything back
- Scaling is a procurement decision, not an engineering one
When the platform is a single large instance, there is exactly one way to handle growth: a bigger instance. That is not a technical operation. It is a capital request, a vendor negotiation, a hardware lead time, a change board and a migration window.
The practical effect is that capacity planning happens a year or more ahead, on forecasts nobody believes. Teams over-provision because under-provisioning is career-limiting, and the organisation pays for headroom it does not use. It also means the platform team cannot say yes quickly. A product manager who wants to triple transaction volume for a fortnight is asking a yes or no question, and the honest answer is “not this quarter”.
- The standby that has never been tested in anger
Almost every organisation in this position has a documented DR arrangement. Far fewer have one exercised under real failure conditions, with real traffic, unannounced.
In a primary and standby model, failover is a discrete, manual, high-stakes event: promote the standby, repoint applications, verify consistency, and accept that you may have lost transactions. So it gets tested the way it can be tested safely, on a Sunday, announced weeks ahead.
Meanwhile the annual DR test reported to the board is frequently a document review. Someone confirms the runbook exists, the replication link is up, and the RPO and RTO targets are written down. Nobody pulls the power.
The numbers themselves deserve the same scepticism. In a standby architecture the true recovery point depends on replication lag at the moment of failure, and the true recovery time depends on how quickly a specific group of people can be assembled and how confident they feel. Neither is a property of the system. Regulators increasingly ask for evidence of tested resilience rather than documented intent, and this architecture struggles to supply it honestly.
- Maintenance windows in a business that no longer has quiet hours
The maintenance window is an artefact of a world where the bank closed at 3pm and the batch ran overnight. That world is gone. Digital channels are used at 2am, quiet hours in Colombo are business hours in Dubai, and payment rails run continuously.
Yet patching, upgrades, index rebuilds and schema changes still require the database to be unavailable or degraded. So they get scheduled months ahead and batched to minimise the number of windows, and the batching itself increases risk because five changes go in at once and any of them could be the problem.
The second-order effect is worse than the downtime. Because windows are scarce, change accumulates and teams hold back improvements they cannot get a slot for. Technical debt here is a queue with a waiting list.
- Every performance problem becomes a commercial problem
Per-core licensing on legacy proprietary relational databases changes the character of engineering decisions. A query that needs more CPU is not a tuning task. It is a licence conversation.
The distortion shows up in odd places. Teams avoid indexes that would help because of overhead on a constrained box. They push logic into the application to avoid database load. They keep old data in the primary because archiving requires a project. They run reporting against the transactional system at night because a separate instance means separate licences.
Over time the organisation builds an architecture optimised for the licence model rather than the workload. That is an expensive way to be slow.
- Data residency pulling one way, consolidation pulling the other
Across the Gulf, regulators and sector authorities in the UAE, Saudi Arabia and Qatar have moved towards requirements that certain categories of data, particularly government, telecommunications and financial data, are stored and processed in-country. In India, regulators including the RBI have set expectations on where payment system data resides. Sri Lanka and Bangladesh have data protection regimes maturing on similar lines, and Singapore’s PDPA governs transfers out.
At the same time, regional groups headquartered in Singapore or Dubai want the opposite: one platform, one operating model, one set of engineers, consolidated reporting across every market.
The usual resolution is a separate database stack per country: separate instances, licences, DR, patching schedules and on-call. The consolidation programme quietly becomes several parallel local programmes with a shared logo, and the group CIO gets a report assembled by copying data between countries, which is the exact activity the residency rule was written to constrain.
- The core system that holds the truth and releases it once a night
Underneath all of this, in a large share of banks and insurers across India, Sri Lanka and Bangladesh, sits a core platform on IBM i, still commonly called the AS/400 internally. It is not there by accident. It works, it has been stable for decades, and the business logic encoded in it is documented nowhere else.
The problem is not the platform. It is how data leaves it. In most cases the answer is a nightly batch extract: a job runs after end-of-day processing, produces flat files, and downstream jobs load those files into the data warehouse, the analytics environment, the customer data platform and whatever the digital channel reads from.
The consequence is visible to every customer. The mobile app shows yesterday. The call centre agent sees a balance that has not moved since last night. The fraud team analyses transactions that are already many hours old. The relationship manager gets a churn alert about a customer who closed the account two days ago.
And when the business asks for an AI use case, whether next-best-action, real-time fraud scoring or an assistant that can answer a customer’s actual account question, the blocker is not the model. It is that the freshest data available outside the core is stale by design.
Why the usual fixes make it worse
Faced with this, most organisations reach for the same three remedies. Each relieves a symptom and adds a permanent operational liability.
More read replicas. Reporting is slowing the primary, so add replicas and point reads at them. Now replication lag is a first-class application concern. A customer makes a payment, refreshes, and the balance is unchanged because that read went to a replica running seconds behind. So developers route certain reads back to the primary, reintroducing the load you were trying to move, and correctness now depends on every developer remembering which reads are safe.
More ETL. The data is stale, so add pipelines. Each has a schedule, a failure mode, a person who understands it and a downstream consumer who notices a day late when it breaks. The number of pipelines only grows, because nobody gets funding to decommission one. Eventually much of the platform team’s week goes on operating data movement rather than improving the platform.
More caching. Latency is bad, so put a cache in front. Now there is a second copy of your data with its own consistency semantics, invalidation bugs and failure behaviour under load. Invalidation problems surface as intermittent, unreproducible customer complaints, the most expensive kind.
The pattern is the same in all three. Each remedy adds a component that compensates for a property the database does not have, and each brings its own consistency model. You do not end up with one system that is hard to reason about. You end up with five, and the interactions between them are undocumented.
There is a quieter cost too. Every one of these layers has to be patched, monitored, capacity-planned and staffed. The team meant to be delivering modernisation ends up running a distributed system nobody designed, assembled from parts chosen to work around a decision made in 2009.
How YugabyteDB approaches the data layer differently
YugabyteDB is a distributed SQL database. The distinction that matters is not positioning. It is that the properties the architecture above is trying to bolt on are properties of the database itself.
Data is automatically split into units called tablets and distributed across the cluster’s nodes. Each tablet is replicated to multiple nodes using the Raft consensus protocol, with a leader and followers per tablet. That mechanism is the source of most of the operational difference.
When a node fails, the tablets for which it held leadership automatically elect new leaders from the surviving replicas. There is no promotion procedure, no runbook, no group assembling on a call. The same mechanism handles the loss of an availability zone and, with an appropriate topology, the loss of a region. Failure handling becomes routine rather than an event, which means it can be exercised honestly and often.
Scaling works on the same principle. Adding a node rebalances tablets onto it and capacity increases. Removing a node moves them off. Growth stops being a procurement cycle with an outage at the end.
1. PostgreSQL compatibility is the part that makes this practical
YugabyteDB’s primary API, YSQL, is PostgreSQL-compatible and reuses the PostgreSQL query layer, supporting stored procedures, triggers and extensions. A Cassandra-inspired API, YCQL, is also available for workloads that suit it.
This matters more than any single distributed-systems feature, because it determines whether modernisation is feasible at all. Existing PostgreSQL drivers, ORMs, tooling and operational knowledge carry across, and applications built against PostgreSQL do not need rewriting to sit on a distributed foundation.
For organisations moving off legacy proprietary relational databases, Yugabyte also provides YugabyteDB Voyager, a migration tool for moving schema and data from other databases onto YugabyteDB. That turns migration into a defined engineering exercise rather than an open-ended risk.
2. Geo-partitioning: one logical database, data held where the law requires
This is the capability that resolves the residency-versus-consolidation tension described earlier, and it deserves attention because it is genuinely different from running separate stacks.
YugabyteDB supports row-level geo-partitioning. You designate a partition column, typically a country or region identifier, and use tablespaces to pin each partition to specific cloud regions and availability zones. Rows for UAE customers physically reside in UAE infrastructure, rows for Indian customers in India, rows for Sri Lankan customers in Sri Lanka.
The important part is that this is still one logical database. Applications connect to one cluster and query one schema. Group reporting works without a data movement pipeline between countries. Your engineers operate one platform, with one set of procedures, one patching model and one monitoring stack.
Yugabyte’s own documentation gives regulatory data residency as the driving use case for this feature, including requirements to keep payment data within India. That is what it was built for.
3. Deployment and operating model
YugabyteDB has an open source core. It is available as self-managed software, with YugabyteDB Anywhere for organisations running clusters in their own data centres or cloud accounts, and as YugabyteDB Aeon, a fully managed cloud service. AWS, Google Cloud and Microsoft Azure are supported, as are on-premises and hybrid topologies. That range matters here: a bank in Dhaka that must run in its own data centre and a regional insurer consolidating across three clouds can adopt the same technology under different operating models.
How Gluesync from MOLO17 bridges the core systems
Distributed SQL solves the target-state problem. It does not, on its own, solve the problem that your authoritative data sits in a core platform that is not moving in this budget cycle.
That is where Gluesync, MOLO17’s real-time data integration platform, does specific work. It performs change data capture and real-time replication across a wide range of sources and targets, including relational and NoSQL databases, data warehouses, event streaming platforms such as Apache Kafka, cloud object storage, and YugabyteDB itself.
The capability that matters most for this region is its IBM i support. Gluesync’s IBM i Series Agent connects to Db2 for IBM i using the IBM JTOpen JDBC driver over TLS, and performs change data capture using IBM i’s native journal APIs, specifically QjoRetrieveJournalEntries. It reads committed changes from journal receivers and filters out rolled-back operations during parsing. It supports Db2 for IBM i from version 7.1 onwards, acts as both source and target, and handles full-table snapshots and bulk loading for the initial seed.
The practical consequence is that changes on the core become a stream rather than a nightly file. Instead of the mobile app showing yesterday, it reads from a modern database kept current from the core continuously.
Gluesync is a cloud-native, containerised platform, deployable on AWS, Azure and Google Cloud or on-premises via Kubernetes, with a no-code configuration interface rather than hand-built integration code. It supports bi-directional synchronisation, allowing patterns where a modern application writes and the core remains authoritative.
This is what makes modernisation incremental. You no longer choose between leaving the core alone and replacing it. You put a real-time bridge between the core and a distributed SQL platform, move workloads across one at a time, and let the core keep doing what it does well until the case for retiring it is actually made.
What this looks like in practice
Work through a regional bank with its core on IBM i in Colombo, digital channels serving Sri Lanka, Bangladesh and the UAE, and a group function in Singapore that wants consolidated reporting.
- Stand up a YugabyteDB cluster with nodes in each required jurisdiction, sized for the digital channel workload rather than the whole estate.
- Define geo-partitioning on customer and transaction tables, using tablespaces to pin each country’s rows to that country’s infrastructure.
- Deploy Gluesync and configure the IBM i Series Agent against Db2 for IBM i, starting with a full snapshot of the tables the digital channels need.
- Switch to continuous journal-based change data capture, so balances, transactions and customer records flow into YugabyteDB as they commit on the core.
- Repoint the mobile and internet banking read paths at YugabyteDB. Customers see current data, and load comes off the core.
- Move a new workload, a customer engagement or fraud scoring service, to write directly to YugabyteDB, with the core kept in step where required.
- Test resilience properly. Take a node out during business hours, then a zone. The cluster re-elects leaders and continues, and you have evidence rather than a document.
- Report at group level with one query against one logical database, each country’s data still resident where the regulator requires it.
At no point is there a big-bang cutover, and at no point is the core at risk.
Matching the problem to the capability
| Challenge | How this architecture addresses it |
|---|---|
| Scaling means buying a bigger machine and taking an outage | Horizontal scale-out by adding nodes, with automatic tablet rebalancing, performed during business hours |
| Failover is a manual, high-stakes event that is rarely tested honestly | Raft-based replication with automatic leader election on node, zone or region failure, exercisable as routine |
| Maintenance windows block change in a 24×7 business | Node-level operations against a replicated cluster rather than a single instance holding the whole workload |
| Per-core licensing turns tuning into a commercial negotiation | Open source core with self-managed and managed options, so capacity decisions are engineering decisions |
| Data residency conflicts with regional consolidation | Row-level geo-partitioning with tablespaces pinning rows to specific regions inside one logical database |
| Core data is only available as a nightly batch extract | Gluesync change data capture from Db2 for IBM i via native journal APIs, delivering changes continuously |
| Migration off legacy platforms is open-ended risk | PostgreSQL compatibility through YSQL, plus YugabyteDB Voyager for schema and data migration |
Who benefits most
- Banks and insurers in India, Sri Lanka and Bangladesh with long-lived core systems. Particularly where the core is on IBM i, digital channels are growing faster than the batch architecture can serve them, and there is board pressure on real-time capability and AI use cases.
- Telecommunications operators and government entities in the Gulf. Where in-country storage and processing requirements are explicit, workloads are continuous, and the alternative to geo-partitioning is duplicating infrastructure per jurisdiction.
- Regional groups headquartered in Singapore or Dubai. Running the same business across several countries on parallel database estates, and paying for that duplication in licences, headcount and reporting latency.
- Organisations whose cloud programme has stalled at the data layer. If your applications are cloud-native and your database is not, the harder cultural work is done. What remains is an architecture decision.
Not a database question
This is usually framed as a database question. It is not. It is a question about whether your data layer can support the commitments your organisation has already made to its customers and its regulators.
You have promised 24×7 availability. You have accepted residency obligations. You have told the board there is an AI roadmap. Each of those assumes a data layer that can scale without a procurement cycle, survive failure without a runbook, keep data in a jurisdiction without duplicating the estate, and make current information available outside the core.
A single large instance with a warm standby cannot deliver those things, and no amount of replicas, pipelines or caches in front of it will change that. The layer has to change, but it no longer has to change all at once. A distributed SQL foundation with PostgreSQL compatibility, paired with real-time replication off the platforms you are not ready to touch, makes modernisation incremental, with evidence at each step.
EGUARDIAN distributes and supports both YugabyteDB and MOLO17’s Gluesync across Sri Lanka, India, Bangladesh, Singapore, the UAE and the wider Middle East, working with channel partners and end customers on architecture, proof of concept and deployment.
Talk to our experts at EGUARDIAN. If your modernisation programme has done good work everywhere except the data layer, let us look at your core systems, your residency obligations and what a distributed data foundation could look like for your organisation. Reach out to us at hello@eguardian.com.
