Schedule Meeting


MariaDB Catalogs: some use cases

by | Oct 11, 2023 | MariaDB Features

Need Help?  Click Here for Expert Support

This month I attended Monty’s talk about Catalogs at MariaDB Server Fest 2023 in Helsinki.

He described this nice feature, which is still under development, and how it will work. But when he talked about the use cases, I was under the impression that catalogs have more use cases than he thought (as I told him later).

In this article, I’ll summarise what catalogs are and explain how I think they can be useful to many organisations.

Catalogs in brief

You probably know that MariaDB databases are more or less similar to what other DBMSs call schemas. In this perspective, you can think MariaDB catalogs as an equivalent for other DBMSs databases. A user with normal privileges will connect to a catalog and will not know anything about other catalogs. Replication can replicate data from or to a specific catalog.

Catalogs are mostly about isolation. However, Monty stressed that they won’t provide total isolation, because if a catalog user somehow causes MariaDB to slow down or crash, all users will be affected.

Backward compatibility will be preserved: if you connect to MariaDB without specifying a catalog, you’ll connect to the def catalog. If you want to connect to a specific catalog but your library doesn’t support this option, a catalog can be bound to a specific IP and/or port.

How catalogs can help you

Monty mentioned that catalogs can be used for multi-tenancy setups. He explained that, instead of using a virtual machine or container for each customer, an organisation can have a catalog for each customer distributed on a smaller number of MariaDB servers. The purpose is to save resources. I’d only recommend this if costs are a concern, which is actually the case for some organisations, like hosting providers.

But let’s see some other cases that, I believe, apply to most organisations.

Use case: development databases managed by DBAs

I think that a much more common use case is development databases. Normally staging databases are in the cloud, where development databases are located on each developer’s laptop. This typically means that development databases differ from staging and production in many ways:

  • MariaDB versions.
  • Even the MariaDB/MySQL flavour! I remember people using MariaDB in development when they had MySQL in production.
  • Much of the configuration, including variables like sql_mode or collation_server that affect the meaning of SQL queries.
  • Normally developers don’t feed big local databases. That’s why “this beautiful cross-join between 7 tables is blazing fast on my laptop but slow in production, you DBAs messed up our servers and try to blame us!”.
  • DBAs or DevOps might write automation to launch and feed dev databases, but developers will have to use these procedures. DBAs or DevOps have to trust that developers follow the procedures correctly, and support them if something doesn’t work, if MariaDB crashes, if data gets corrupted, etc.

Without catalogs, the solution to all these problems would be easy but unreasonably expensive: having a remote development environment, maintained by the DBA, with a server for each developer. This is essential to isolate each developer’s work from others without changing database names, which would increase complexity in many ways.

To me, catalogs seem the perfect solution. They provide every developer with the isolation they need. DBAs can always make sure that the MariaDB version and configuration match production. Even if a developer manages to crash MariaDB, I’d say that this is not a big problem: other developers can wait until MariaDB restarts. But if you disagree on this, you can always have another instance containing the same catalogs, to allow disruptions.

Use case: lightweight microservices

Many companies use microservices. One of the principles of microservices is isolation: they should run on different servers, and use different database servers.

But in practice, some companies have many microservices, and some of them are almost idle. So, following the isolation principle too strictly might sound like a waste of money. Let’s suppose you have 10 microservices and 4 of them are almost idle. Would you really want to have a separate Galera Cluster, a proxy layer, and backup infrastructure for each microservice? Probably not – or at least, it depends on your budget.

But if you have to run multiple microservices on the same cluster, having some more isolation would help. So you might at least create a catalog for each microservice, reducing the chances that microservices interfere with each other. This is another very common use case.

Use case: superuser isolation

Only users in the def catalog will be permitted to run certain operations, such as controlling replication. Creating all regular users in other catalogs guarantees that the superuser can’t give them certain permissions accidentally.

This use case applies to any server, even if it is going to only contain one database. Just don’t store databases in the def catalog.

Use case: emulating other DBMSs

This is much less frequent, but still potentially interesting.

You might have tools or applications that are written to work with another DBMS, and you might need to get them working with MariaDB. And maybe they do something with both databases and schemas.

Catalogs can be used as databases. You’ll just have to make minor changes to some SQL commands. Schemas might be easy as well, as the SCHEMA and SCHEMAS keywords exist in MariaDB and can always be used as synonyms for DATABASE and DATABASES. You might just have to translate another DBMS command into MariaDB’s USE.


The first two use cases I mentioned are extremely common. More likely than not, if your organisation uses MariaDB, you could benefit from at least one of them.

But I’m also sure that there are possible use cases that didn’t cross my mind. If you think you might use schemas in a way that I didn’t consider, please let us know with a comment. Also, consider contacting us to take advantage of our assistance in implementing catalogs in your MariaDB servers.

You can also attend my webinar covering MariaDB 11 features, including catalogs, on November 15, 2023, the registration is now open:

Federico Razzoli

All content in this blog is distributed under the CreativeCommons Attribution-ShareAlike 4.0 International license. You can use it for your needs and even modify it, but please refer to Vettabase and the author of the original post. Read more about the terms and conditions:

About Federico Razzoli
Federico Razzoli is a database professional, with a preference for open source databases, who has been working with DBMSs since year 2000. In the past 20+ years, he served in a number of companies as a DBA, Database Engineer, Database Consultant and Software Developer. In 2016, Federico summarized his extensive experience with MariaDB in the “Mastering MariaDB” book published by Packt. Being an experienced database events speaker, Federico speaks at professional conferences and meetups and conducts database trainings. He is also a supporter and advocate of open source software. As the Director of Vettabase, Federico does business worldwide but prefers to do it from Scotland where he lives.

Recent Posts

The UUID data type in MariaDB

The UUID data type in MariaDB

MariaDB introduced the UUID data type in version 10.7. The first long-term support (LTS) version to include it is 10.11, which was declared stable in February 2023.

A summary of MariaDB 10.10: INET4 type, RANDOM_BYTES() and more

A summary of MariaDB 10.10: INET4 type, RANDOM_BYTES() and more

In my first post in 2023, I want to give you a summary of MariaDB 10.10. Some may argue that I'm a bit late because it was released last November, and versions 10.11 and 11.0 have been announced since then... All that is correct, but 10.10 is the latest stable...


Need Help?  Click Here for Expert Support


Submit a Comment

Your email address will not be published. Required fields are marked *