# How Klarna Migrated the KRED System from Mnesia to Postgres with Zero Downtime

DevFeed: [How Klarna Migrated the KRED System from Mnesia to Postgres with Zero Downtime](<https://devfeed.tech/articles/the-fellowship-of-the-forgotten-35655.md>)

Original publisher: [Read original article](<https://engineering.klarna.com/the-fellowship-of-the-forgotten-d341045a6123?source=rss----86090d14ab52---4>)

Author: Onno Vos Dev

Published: 2025-02-26T09:04:27Z

Content type: article

Language: en

Sources: [Klarna Engineering](<https://devfeed.tech/sources/klarna-engineering.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [Erlang](<https://devfeed.tech/topics/erlang.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [sharding](<https://devfeed.tech/topics/sharding.md>), [Transactions](<https://devfeed.tech/topics/transactions.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [cluster](<https://devfeed.tech/tags/cluster.md>), [databases](<https://devfeed.tech/tags/databases.md>), [erlang](<https://devfeed.tech/tags/erlang.md>), [klarna](<https://devfeed.tech/tags/klarna.md>), [memory](<https://devfeed.tech/tags/memory.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [production](<https://devfeed.tech/tags/production.md>), [replication](<https://devfeed.tech/tags/replication.md>), [scaling](<https://devfeed.tech/tags/scaling.md>), [sharding](<https://devfeed.tech/tags/sharding.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>), [transactions](<https://devfeed.tech/tags/transactions.md>)

## AI overview

This article describes Klarna's migration of KRED, an Erlang servicing system, from Mnesia to Postgres with zero downtime. It explains the original replicated seven-node architecture, the system's scaling challenges, and a plan involving sharding across multiple clusters.

## Source excerpt

How we migrated from Mnesia to Postgres with zero downtime Back in December 2004, an Erlang application was born called KRED (referring to the freshly-started company called Kreditor, now known as Klarna). KRED is one of the "servicing systems" at Klarna and keeps track of consumer debt (among other things). It was powered by Mnesia and consisted of a cluster of 7 nodes, each holding a full copy of the database on disk. The data was replicated using a custom replication mechanism built in-house by Klarna. One node was elected as the leader and its database was considered the source of truth in the system. All database transactions were executed on the leader and writes were replicated to the rest of the nodes, the so-called followers. The Mnesia database was around 15 TB and at its peak in 2018 around 1.3 TB was held in memory at all times. Considering that few suppliers were selling hardware with such specs, it's easy to claim the crown of one of the biggest Mnesia databases in terms of in-memory storage, that was running in production. The rest of the data was offloaded to disk using mnesia_eleveldb. KRED has been a stable workhorse at Klarna so why change a winning concept? Get ready, for a two part blog post where we'll first go through our journey of how we went about this and secondly, how we made Mnesia behave just like Postgres and implemented our version serializable isolation level on top of Postgres! How the journey started Three engineers, sat down in a bar in Stockholm, Sweden and asked this question: 'When Klarna truly takes off, will KRED survive? Assuming "no", and presented with a blanco check, how would we tackle this problem?' The answer quickly revolved around the issues of running Mnesia on an even larger cluster and with leveldb compaction hitting some hot tables during peak times. One can only imagine how that problem would just continue to get worse over time. Considering the three engineers had worked on KRED for a long time, scaling KRED wa