--- title: "Why MariaDB is giving financial services a cache of its own" publish_date: 2026-11-06 author: "Mani Nagasundaram" channel: - name: "Product" url: "/resources/blog/channel/product.md" tags: - name: "Cache" url: "/resources/blog/tag/cache.md" - name: "Distributed SQL" url: "/resources/blog/tag/distributed-sql.md" - name: "finance" url: "/resources/blog/tag/finance.md" - name: "Financial Services" url: "/resources/blog/tag/financial-services.md" - name: "Finos" url: "/resources/blog/tag/finos.md" - name: "GridGain" url: "/resources/blog/tag/gridgain.md" - name: "Kevat" url: "/resources/blog/tag/kevat.md" --- # Why MariaDB is giving financial services a cache of its own Table of contents 1. [Why we’re doing this](#why-were-doing-this) 2. [Why FINOS and what the financial services community gets](#why-finos-and-what-the-financial-services-community-gets) 3. [What’s in it for MariaDB and why curation is the point](#whats-in-it-for-mariadb-and-why-curation-is-the-point) 4. [What’s next](#whats-next) ## Key takeaways - MariaDB and FINOS announced Kevät, an open source distributed in-memory cache built around the needs of financial services, at the Open Source in Finance Forum in New York. - MariaDB is seeding the project with a version of the MariaDB GridGain codebase and is the project’s maintainer at launch. - A number of high-profile banks have joined the founding advisory committee to steer the roadmap alongside their peers. - Kevät is designed to deliver low latency at scale with security, auditability and compliance built in, as banks put AI agents onto live financial data. - The initial code is in FINOS’s standard contribution review and is expected on the FINOS GitHub in early 2027. Nobody has ever said “I’m so excited about our in-memory cache” at a dinner party. And yet these unglamorous layers sit underneath risk calculation, trading and payments, and they are about to get a lot more important in the agentic world. Today, at the Open Source in Finance Forum in New York, MariaDB and [FINOS](https://www.finos.org/), the Fintech Open Source Foundation, announced Kevät, an open source distributed in-memory cache for financial services. MariaDB is seeding the project with a version of the [MariaDB GridGain](https://mariadb.com/resources/datasheets/mariadb-gridgain/) codebase, and a number of high-profile banks have joined the founding advisory committee. MariaDB is the maintainer of the project at launch, with more maintainers to follow as the project grows. ## Why we’re doing this Banks are putting AI agents onto live financial data. Agents don’t browse politely. They read and act at machine speed, with access patterns the infrastructure underneath wasn’t built for. At the same time, regulators will expect institutions to show who or what touched which data and why, and the rules differ by country and are still being written. The data backs this up. [FINOS’s 2026 State of Open Source in Financial Services report](https://www.finos.org/state-of-open-source-in-financial-services), published this week, found that 64% of survey respondents work at organizations that have already deployed agentic AI in production. Yet security and privacy risks (52%) and auditability and explainability (38%) rank among the biggest barriers to doing more, and the report concludes that governance, not technology, is the main constraint. That is the gap Kevät is designed to help close. The open source caches available today are general-purpose by design. They serve every industry, which is wonderful, but it means none of them were designed with these specific financial services demands in mind. Financial institutions need low latency at scale, with security, auditability and compliance built in rather than bolted on. We think the best way to get there is to build it in the open, alongside the people who will run it. ## Why FINOS and what the financial services community gets We could have kept this under our own roof and decided the roadmap ourselves. But we wanted a home where the institutions relying on the software have a real say in where it goes, and that’s exactly what FINOS offers. FINOS is part of the Linux Foundation and offers a neutral, well-governed setting designed by regulated institutions for regulated institutions. For FINOS and its members, that means a foundational piece of data infrastructure with a roadmap steered by the banks themselves. Advisory committee members help set priorities alongside their peers, rather than filing feature requests into a vendor’s backlog and hoping for the best. It also means no one gets locked in. The code is open, the governance is neutral and the direction belongs to the institutions that rely on it. We also want Kevät to be built by more than one company. FINOS brings banks, technology firms and individual developers together to work on shared problems, which makes it the right forum for others to contribute code, fixes and ideas. MariaDB is seeding the project, but we hope to see contributions from across the industry, and we expect new maintainers to come from that community as the project grows. ## What’s in it for MariaDB and why curation is the point You’re probably wondering what’s in it for us and fair enough. Part of the answer is who we are. Open source is where MariaDB started and where we keep investing. MariaDB Server, the foundation for our enterprise platform, has been downloaded more than 3 billion times, and our open source work extends to connectors, the Kubernetes Operator, our MCP server and AI integrations. Contributing the initial open source code for Kevät is a natural next step for us. Open source has won and nobody in a bank’s technology leadership seriously doubts that anymore. The harder question is how to consume it responsibly when you’re regulated. Raw open source is a bit like a vast market stall. Wonderful range, variable quality and no one to ask if something goes wrong. Regulated institutions can’t just grab what looks good. They need to know where code came from, who maintains it, how vulnerabilities are handled, how it will be supported in five years and how it fits their compliance obligations. That is the job of curation: selecting, hardening, governing and supporting open source so it is fit for production in a regulated environment. The FINOS report shows the need is real: 71% of respondents maintain internal forks of open source projects, and 40% name a lack of ongoing maintenance or support as a top concern. That’s the role we want MariaDB to play and it’s where our interest lies. Not as the owner of open source, but as a provider of [curated open source software](https://mariadb.com/why-mariadb/#accountable) that financial institutions depend on. A cache shaped by the institutions that use it will be a better cache, and as the maintainer we get close, continuous feedback from some of the most advanced technology teams in the world. Kevät is the first clear expression of that: open code, neutral governance, finance-led direction and a maintainer who will stand behind it. We believe that’s good for everyone. ## What’s next The initial code is going through FINOS’s standard contribution review before it is published, and we expect it on the FINOS GitHub in early 2027. Contributions from banks, technology firms and developers are welcome from day one. If you’ve ever wished your cache understood what a regulator is, come and help us teach it. **Reference** [The 2026 State of Open Source in Financial Services](https://www.finos.org/2026-state-of-open-source-in-financial-services-download), FINOS and Linux Foundation Research, November 2026. ### **What is Kevät?** Kevät is an open source distributed in-memory cache designed around the needs of financial services. MariaDB and FINOS announced it at the Open Source in Finance Forum in New York, and the project is governed under FINOS, part of the Linux Foundation. MariaDB is seeding Kevät with a version of the MariaDB GridGain codebase licensed under Apache 2.0, and a founding advisory committee of banks will help set its direction. ### **What is a distributed in-memory cache?** A distributed in-memory cache keeps frequently used data in RAM across a cluster of servers, so applications can read it from memory instead of going back to the database every time. That cuts response times to under a millisecond. Because the data is spread across many nodes, the cache scales by adding servers and, with replicas configured, keeps serving data if a node fails. In financial services, caches like this sit underneath risk calculation, trading and payments. ### **What is MariaDB GridGain?** MariaDB GridGain is the distributed in-memory caching and compute layer of the [MariaDB Enterprise Platform](https://mariadb.com/products/platform/). It sits between applications and systems of record and keeps hot data in memory for sub-millisecond response times, with ANSI SQL, ACID transactions and compute that runs on the nodes where the data lives. It also supports AI workloads such as semantic caching and agent memory. At one global top 5 bank, it cut a risk calculation from 3 minutes to 600 milliseconds. Read more in the [MariaDB GridGain datasheet](https://mariadb.com/resources/datasheets/mariadb-gridgain/). ### **What is FINOS?** [FINOS](https://www.finos.org/), the Fintech Open Source Foundation, is part of the Linux Foundation. It gives banks and other financial institutions a neutral, well-governed home to build open source software together, with governance designed by regulated institutions for regulated institutions. ### **Why do financial services need their own cache?** The open source caches available today are general-purpose and serve every industry, so none were designed around the specific demands of financial services. As banks put AI agents onto live financial data, they need low latency at scale with security, auditability and compliance built in rather than bolted on. FINOS’s [2026 State of Open Source in Financial Services report](https://www.finos.org/state-of-open-source-in-financial-services) found that 64% of respondents work at organizations that have already deployed agentic AI in production, while security and privacy risks (52%) and auditability and explainability (38%) rank among the biggest barriers to doing more. ### **Who sets the roadmap for Kevät?** The direction belongs to the financial institutions that rely on it. A number of high-profile banks have joined the founding advisory committee, where they help set priorities for the project alongside their peers. ### **Who maintains Kevät?** MariaDB is the maintainer of the project at launch, with more maintainers to follow as the project grows. Regulated institutions need to know who maintains the code they run, how vulnerabilities are handled and how it will be supported over time, and MariaDB is committed to standing behind it. ### **When will the Kevät code be available?** The initial code is going through FINOS’s standard contribution review before it is published. MariaDB expects it to be available on the FINOS GitHub in early 2027.