Database Modeling & Schema

In this section, you will find important information about the data saved by Midaz.


Context

Midaz uses three main database models to save information for each of its domains, which will be better described below.

It's worth noting that, as it's an open-source project, the data topology tends to change over time, and when this occurs, users will be informed so they can decide how to carry out the update in their instances.

For Midaz users in the SaaS model, such updates are transparent, and it's sufficient for the user to use the endpoints (or DSL) of the new version and, instead of using POST /v1/organizations, use POST /v2/organizations.

Relational databases

The Onboarding and Portfolio domains use a relational database to store their data, given that those entities might have their information updated or deleted.

ImmuDB

For the Transactions domain, we rely on ImmuDB to provide us the immutability and resilience needed for the double-entry ledger.

Non-relational databases

To store the content of metadata, we use non-relational databases to provide us with better performance when searching for JSON objects sent by the users. The default NoSQL database used by Midaz is MongoDB, but users can select another one that better fits their needs.

Database modeling

The diagrams below show the relationship between the entities when it comes to their tables inside the databases.

Onboarding domain

Portfolio domain

Transactions domain

Data profile

Down below you can find the data profile for each table of Midaz.

Onboarding domain

The tables for the Onboarding domain are shown below.

Organizations table

Ledgers table

Portfolio domain

The tables for the Portfolio domain are shown below.

Assets table

Portfolios table

Accounts table

Products table

Transactions domain

The tables for the Transactions domain are shown below.

Transactions table

Operations table

Assets rates table

Data migration

  • data migration and backward compatibility

Last updated