What Azure Database should I use for FinTech in 2026?

When you start a new FinTech software project on Azure today, do you reach for SQL Server? CosmosDB? PostgreSQL?

It's not an easy question to answer. We've debated it a lot internally and have come up with our own recommendation. Below, I'll share our thinking. You may not reach the same conclusion as we did – your circumstances may be different.

The tension with CosmosDB

For a long time, we as an industry have moved towards document databases rather than relational databases for many systems – and we've built many systems, very happily, on CosmosDB. There are good reasons for this. To name just a few:

• It's, for the most part, very easy to evolve a data structure or schema over time without worrying about schema migrations.
• Conceptually, document databases align much more closely with our programming languages. In effect, we can just store and retrieve object graphs.
• The performance is astonishing, in part because what would require multiple queries and joins in a relational database can often be done by retrieving one or two documents from a document database.
• There's a neat pattern we often use for low-value data (non-financial, low-impact data): we can store an opaque JSON blob in the document database and pass it wholesale to and from the front end for rendering and editing. It saves the server having to understand those data structures at all, while still allowing us to report on it.

However, for systems that handle financial data, there are some substantial downsides, including:

• There's no concept of referential integrity, nor of joins between documents. For a financial system, this is a big deal for both data quality and reporting.
• Until very recently, cross-partition transactional integrity was missing. Distributed transactions are now in public preview, which closes some of that gap.
• Long-running, server-side cross-partition aggregations don't have snapshot consistency: the results may or may not include records written after the query started running.
• Reporting tools such as Power BI can, technically, read CosmosDB. But without a native concept of tables and foreign keys, it takes a lot more effort for users to extract the data they want. This is generally solved with some kind of CQRS-style approach, either rolling up into reporting documents or copying data to a relational database for reporting purposes. Azure provides several native ways to do this copying, so you don't need to hand-roll it, including Mirroring in Microsoft Fabric and Change Feed.
• Denormalised data and handling cascading updates in code is a fact of life with document databases. It's subjective, but we've found this to be more of a concern in financial systems than in other types of systems, given the typical structure and nature of the data.

In financial systems, we generally want relational database features. But we also want the convenience of documents for all the non-money-related data. So, what to do?

Combination

We've successfully used a combination of SQL Server and CosmosDB in the same application. It works well when you have relatively discrete bounded contexts. The downside is that you have to work out a way of linking records across the two databases without enforced referential integrity, and you take on the impedance mismatch of working with two different storage paradigms in the same codebase.

PostgreSQL

PostgreSQL natively supports both documents/objects and relational records. The "documents" live inside a record in a table, so it's not quite as free-form as a full-blown document database, but it's still very good.

PostgreSQL's object support is very mature and supports excellent indexing and searching. It's probably the most mature offering when it comes to combining relational data and documents in a single database.

It also has the Marten library, which implements event sourcing on top of PostgreSQL. Event sourcing is an excellent pattern in FinTech systems. One thing to note: Marten covers event sourcing and document support, but not relational database features, so you'll likely use Marten alongside EF Core or Npgsql.

The main downside to PostgreSQL is that it's not a fully "native" database offering on Azure. To be clear – Azure Database for PostgreSQL is excellent, it's just not quite as mature and flexible as Azure SQL and CosmosDB, though it's catching up fast.

Generally speaking, for larger workloads, Azure Database for PostgreSQL is great. It's when you want to run smaller workloads – including a separate UAT system – that it becomes a bit more annoying.

For example, Azure Database for PostgreSQL now has the ability to suggest indexes you should drop or create – but only when you provision a server with at least 4 vCores. And the recommendations can't be automatically applied, unlike in Azure SQL.

There's also the fact that you even need the concept of a server: Azure SQL and CosmosDB are much more abstract (an Azure SQL Server is really just a label, not a physical server). So you need to look after your PostgreSQL instance on Azure a bit more than you have to look after Azure SQL or CosmosDB. This is an important consideration, depending on the composition of your team and how much you want to deploy a system and then not have to do much maintenance on it.

Azure SQL

SQL Server significantly improved its JSON support in 2025. This has closed the gap with PostgreSQL considerably, though PostgreSQL still holds the edge.

There are still several features that are in preview and not yet available in Azure SQL Database, most notably the ability to patch objects (modify()) and the ability to create JSON indexes.

Overall, it's not as nice as using CosmosDB, but it works well enough for relatively simple document-database-style operations, especially when the schemas for the JSON objects are well defined.

If your team is already familiar with Azure SQL and EF Core, you can very happily combine a document database and a relational database in a single database and a single storage paradigm in your app, while benefiting from very mature support in Azure.

Conclusion

Azure SQL is adding document database features, and CosmosDB is adding transactional features. PostgreSQL already has both. There's no slam-dunk answer here – it really depends on your specific use case, the experience of your team, and the level of maintenance you're able to take on.

Our default

It's not perfect, but for now, Azure SQL is the best option for financial systems on Azure – at least for us.

CosmosDB remains our default database for non-financial systems, but we're unlikely to reach for it when building FinTech systems: there tend to be too many things we end up having to handle to ensure integrity and reporting. The improvements being made will make it easier to use CosmosDB for systems that are primarily about non-financial data, with only some financial data mixed in. For anything hard-core FinTech, we can't see it becoming a good contender yet.

What would make us switch to Azure Database for PostgreSQL?

• In some systems, we may need more advanced document-database capabilities while still retaining relational features – for example, path-free indexing in JSON documents.
• As Azure's support matures and the "maintenance tax" comes down, the barrier comes down with it.
• For larger-scale systems, the database cost may actually be lower than SQL Server, since you don't pay for a licence.
• Where event sourcing is relevant, Marten is a good reason to choose PostgreSQL on its own.