"Move fast and break things" is the mantra of today's software development and support. But in the financial sector, breaking things is not an option. When you are dealing with someone else's finances, regulatory compliance, and 30 years of transaction history, financial database migration becomes a high-stakes operation.
We sat down with Vladislav Vlasov, Senior Developer at Ispirer, to discuss why financial institutions are fleeing legacy systems like Oracle and Sybase, why serverless is the new economic reality, and the honest truth about achieving zero downtime.
Let's start with the basics. Is migrating a database for a bank or a fintech company really that different from migrating, say, an e-commerce store?
Vladislav:Absolutely. It comes down to one thing: the ledger.
In a standard application, you care most about the current state: what is the status right now? In fintech, the history is just as important as the present. We have to preserve the original entries — the full journal of operations — alongside the operational data.
So, data volume is the main challenge?
Vladislav:It's not just volume; it's integrity over time. We are dealing with long transactional integrity. You have short transactions (a quick payment) and long synchronization transactions. All of these must land in the new system in a strictly correct state.
The challenge is preventing the database from bloating while keeping this history accessible. If you don't account for this during migration, you risk losing the audit trail, which is unacceptable in finance.
We see a lot of movement in the market right now. What are the most common migration paths you're seeing?
Vladislav:We are seeing a massive exodus from Oracle and Sybase.
Why those two specifically?
Vladislav:You have to look at the history. Many of today's established financial institutions built their tech stacks in the 90s. Back then, Oracle and Sybase were the default choices. But today, the licensing costs are becoming hard to justify, and the architecture is showing its age.
So, where are they going?
Vladislav:PostgreSQL is the undisputed winner. It's not just the standard open-source version; companies are moving to cloud-native Postgres or specialized versions like Postgres Pro.
However, there is a catch. You rarely migrate to just one database anymore.
What do you mean by "not just one database"?
Vladislav:In the past, legacy databases like Oracle tried to be a Swiss Army Knife. They handled everyday transactions and heavy analytics in the same place.
Modern architecture follows a rule we call double denormalization. You separate your transactional work (OLTP) from your analytics (OLAP).
Why can't Postgres handle both?
Vladislav:It can, but it's inefficient for heavy analytics. Transactional databases use isolation methods — essentially keeping "versions" of data to ensure consistency. This is great for safety, but expensive for performance. If you run heavy analytical reports on your live transactional database, simple queries become very expensive in terms of resources.
So, what is the modern solution?
Vladislav:You migrate the operational data to PostgreSQL, and you offload the heavy lifting to a specialized column-oriented database. ClickHouse has become the gold standard for this.
That sounds like it complicates the migration process.
Vladislav: It changes the strategy. You need to build an ETL (Extract, Transform, Load) process immediately during the migration. Don't migrate junk to your shiny new Postgres server. Filter it, and send the historical analytical data directly to the OLAP system.
You mentioned licensing costs earlier. Is cost the only driver for leaving Oracle?
Vladislav: It's about flexibility, too. This is where serverless computing changes things for fintech these days.
With a traditional setup (like on-premise Oracle), you have the provisioning problem:
- If you buy a small server, you run out of space during peak hours.
- If you buy a huge server to handle peaks, you are burning money 90% of the time when traffic is low.
And Serverless fixes this?
Vladislav:Exactly. With Serverless, you don't manage IPs, memory, or physical hardware. You pay for the API endpoints you use. If no one queries the database, you pay zero. If traffic spikes, it scales up instantly. Legacy databases simply cannot offer this elasticity.
Let's talk about the actual switch-over. Every CTO wants zero downtime. Is that realistic?
Vladislav:In theory? No. In practice? We get very close.
When you are working with an ACID-compliant database (which ensures valid transactions), the data is constantly changing. If you are writing to the source database, the target is always playing catch-up.
How do you manage the cutover then?
Vladislav:We focus on replication lag.
Imagine the target database is a runner trying to catch the source database. The target must be more powerful than the source so it can process data faster.
- We migrate the bulk of the history (30 years of data).
- We turn on replication to catch up with recent changes.
- We watch the lag. If the lag drops to, say, 3 hours, we know we are close.
- We schedule a maintenance window (a holiday or a quiet night).
And that's when you switch?
Vladislav:Yes. We stop the source, let the target process that final remaining lag, and then switch the traffic. The downtime is measured in hours, not days.
What about security during this transit?
Vladislav:The rule is simple: direct source-to-target. No intermediate servers. No staging areas outside the perimeter. We pipe encrypted data directly from the safe source to the safe target.
Finally, if you were building a fintech bank from scratch today, what would you choose?
Vladislav: First, avoid the traps. For example, in many cases, you might want to stay away from Sybase. It may have new features, but they are dragging 30 years of legacy logic behind them and want to lock you in for an unreasonably high bill.
Then, choose a relational, isolation-based database (like PostgreSQL) for operations and any other database that fits your business type. And ensure your database has a wide toolkit for connecting to external services and APIs.
The future of fintech isn't about one giant database that does everything; it's about choosing the right specialized tools and connecting them securely.
Read more: Best Database for Financial Data: 2026 Architecture Guide
