We’ve already seen that the Financial Services sector is leading the pack in terms of its adoption of Database DevOps. This has resulted in the ability to deploy changes to production faster, which provides a benchmark for those who are still on the journey to DevOps to aim for. Across every sector, however, one major obstacle to implementing DevOps has arisen: a lack of appropriate skills.

IT teams should consider how this can be addressed by, for example, introducing tooling that streamlines processes and integrates with the existing infrastructure, thereby reducing training requirements.

As much as there is to gain by implementing Database DevOps, there is also a cost to not properly managing the database. Check out this blog for more information.

Over the last decade and more, the type of data being collected, analyzed and used in every business sector has changed. We’ve moved on from structured data typically used in relational databases to semi-structured, unstructured, time-series, geospatial and graph data. This in turn has prompted organizations to introduce different database platforms to better handle that data.

As a result, only 21% of organizations now use only one database platform. For those in Financial Services, this rises slightly to 23%, with the most marked difference being that 49% use two to three different database platforms compared with 36% across other sectors. While the trend is for 42% of organizations to use four or more different database platforms, this also falls to 29%.

There’s a clear sign here that Financial Services organizations have moved to multi-database environments, but they are doing so at a slower pace. This is probably because much of the data they handle is relational transaction data which needs to be ACID compliant. It has to be Atomic, Consistent, Isolated and Durable in order for transactions to be reliable. Traditional relational databases like SQL Server, Oracle and MySQL are particularly known for their robust support of ACID transactions and are therefore more favored.

If you're new to PostgreSQL, try our PostgreSQL 101 series for your introduction to this increasingly dominant data platform.

Almost every organization is now using the cloud in some way, prompted by the instant flexibility it offers compared with fixed on-premises infrastructures. Those in Financial Services are no different and when asked what the primary reasons were for moving to the cloud, the responses were the same as other sectors, with the top three being:

• Scalability and flexibility
• High availability and reliability
• Cost efficiency

This isn’t a one-way street, however, with everything moving to the cloud. It’s more of a junction with organizations using an array of cloud and on-premises infrastructures. Some variances also emerge in Financial Services when looking at where organizations are now hosting their databases. The main difference is that there remains a higher preference for databases to be hosted on-premises. While 36% use all cloud or mostly cloud across all sectors, this falls to 29% in Financial Services.

It appears that many of those organizations in Financial Services who want to move to the cloud have largely done so, as shown by the small bump in those who already host all of their databases in the cloud. This is confirmed when looking at future plans for cloud adoption.

Here, we can see that almost twice as many organizations in Financial Services have already fully migrated to the cloud compared with those in other sectors. We can also see a preference for a hybrid approach to cloud use in future. The scalability and flexibility of the cloud, along with high availability and the cost savings it can offer, makes it an attractive alternative to on-premises hosting.

In Financial Services, there is a higher preference for a hybrid approach, probably due to legacy databases and consistent workloads. The only caveat is that managing and monitoring hybrid estates is more complicated. Care should therefore be taken to ensure the monitoring solution in place can provide a clear picture of the entire estate, and show the status and key metrics in one place.

For every organization everywhere, it seems, AI has arrived and made a big impression with the promise of automating and easing the creation of code, content, and images. When it comes to the development and management of databases, it’s no different, with organizations in every sector either using it or considering it. What’s interesting here isn’t the differences between Financial Services and other sectors: it’s the stark similarities.

And that’s the same with all sectors. Every IT team in every sector is exploring how AI can be used, what the potential benefits are, and where the concerns are that arise from using it.

Along with the benefits that come with AI are the concerns around areas like data, reliability and compliance. No surprise there. AI is interesting, but it comes with a lot of caveats that are still being talked about, with legislation trailing behind. The first legislation is likely to be the EU Artificial Intelligence Act which reached provisional agreement in December 2023 but will likely not come into effect until 2026.

Until then, the top five areas of concerns for every organization in every sector are:

• Data security and privacy
• Accuracy and reliability
• Training / expertise
• Ethical concerns
• Regulatory compliance

AI is, notably, the one area where there is a remarkably similar consensus of opinion across all sectors.

We saw earlier that the leading driver for introducing Database DevOps is to increase the speed of delivery of database changes. In order to achieve this, developers like to test their proposed changes against a realistic, up-to-date copy of the production database. Only by using a copy that is truly representative, with the same size, referential integrity and distribution characteristics can they be sure that their testing will be effective. This, however, raises concerns about the safety of sensitive data that may be in use in development and testing environments.

We can see here that there are various practices used by development teams to protect sensitive data. Some choose Role Based Access Control, limiting the data to specific users, while others mask or de-identify data, or replace it with synthetic data.

Those in Financial Services typically take a more robust approach when it comes to handling sensitive data. Role Based Access Control is around the same, while there’s a big increase in masking or de-identifying data, and using synthetic data. We’re still left, however, with 17% of those in Financial Services either having no approach for handling sensitive data or being unsure. That’s one in six organizations.