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_modeorcollation_serverthat 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.
Conclusions
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: https://meet.zoho.eu/crg8iY2asU
Federico Razzoli
0 Comments