MariaDB Reviews

We are using MariaDB for web applications. Most of our web-related transactions use MariaDB.

Configuration, setup, and schema design are good features in MariaDB. Typical database features we have used include backup, configuration, recovery, archiving, and ETL. When complex query jobs are running, some performance issues have been observed. For example, when querying to get the last year of certain types of transactions with specific characteristics, the processing is comparatively slower. It could be a design issue, but this is simply an apple-to-orange comparison.

Complex queries in MariaDB where the query needs to parse thousands of lines or data values face some performance issues. For small and medium-size volume, it is pretty good. If it goes beyond certain data and complex queries, we see performance issues.

We tried the advanced replication feature between different regions, replicating data specifically residing on MariaDB to two different regions of MariaDB data, and there were some technical snags in terms of slowness and longer processing time.

Point-in-time recovery in MariaDB is good for small databases. When data volume increases beyond 5 GB or 10 GB per day or runs into double-digit GBs, we found some performance issues. For data below 10 GB, it works fine.

Performance is the primary focus area for MariaDB, particularly during transactions or complex query jobs where slow performance is observed. MariaDB is scalable and easy to scale.

We have been using MariaDB for almost one and a half years.

We haven't found issues with the stability of MariaDB. Except for performance, the rest of the factors were quite acceptable. There was not much concern in this area.

The support is good. Whenever we reached out to them, they were always trying to help us out. I would rate them seven or eight out of ten. Compared to MongoDB, there are some platform deficiencies, but the support team shouldn't bear that burden.

Positive

The initial setup of MariaDB requires some experience and learning. There is a learning curve, making it medium complex.

MariaDB is in the pricey range, especially for huge databases handling terabytes of data. The cost depends on the volume of data and different features enabled during configuration, such as backup types and archiving. As data continues to increase across all databases, the cost should decrease moving forward.

We have worked with data-at-rest encryption as part of the configuration, and it worked fine. This feature ensures secured data transfer between various zones, including hybrid, private, and public endpoints.

For AWS suite of products, the plugin capabilities worked seamlessly for MariaDB. However, some compatibility issues existed with certain third-party tools.

We worked on a standalone environment of MariaDB. If the architecture is stacked or enhanced with additional parameters, some of these performance issues might be improved. For small or medium organizations with limited data, MariaDB is suitable. For larger implementations, a specific architecture is needed to handle huge data loads with comfortable performance.

Design factors include options to enhance RAM, memory, and other components to improve performance for huge databases. AWS is applying cost reduction through the credit system depending on the customer type, but this needs to be more accessible to all customer types.

MariaDB is recommended for basic operations or database services for small and medium businesses. For big transactions and real-time transactions, a well-architected model should be used. A thorough deep dive is necessary to set up the environment to cater to specific business needs to avoid performance issues.

Overall rating: 7 out of 10.

My client has been using MariaDB for the last four years. We are using MariaDB in the cloud.

MariaDB is easy to install. Performance of MariaDB has improved with the query optimizer. We use MariaDB's data-at-rest encryption. Encryption is available in MariaDB, so we are secure for transmitting data without concern about moving over networks. Query optimization in MariaDB is better than Oracle. We use advanced replication for MariaDB. Role-based access is available in MariaDB, which is a good feature. The technical support of MariaDB is very helpful. They came and tuned our queries with one-to-one assistance.

Sometimes, complex queries that were supported in Oracle are not available in MariaDB. Advanced indexing is not available. Oracle is very advanced compared to MariaDB, and those advanced features are not available in MariaDB.

My client has been using MariaDB for the last four years.

We do not use point-in-time recovery.

The technical support of MariaDB is very helpful. They came and tuned our queries with one-to-one assistance. I rate the technical support of MariaDB as a 10 out of 10.

Positive

The license of MariaDB is not costly. We were using Oracle, so we moved from Oracle to MariaDB. We moved from Oracle to MariaDB because of price.

MariaDB is easy to install.

I install databases and deployment for MariaDB, including new deployments. In the database, we have our DevOps team that handles deployment. One person is enough for the deployment of MariaDB.

MariaDB does provide some return on investment.

Point-in-time recovery in MariaDB is something we actually use through Amazon only; we do not use it through MariaDB itself. I am a database architect and principal architect. My overall review rating for MariaDB is 7 out of 10.

My main use case for MariaDB was web applications, and I have been using MariaDB for just about a year now as I was in the development team.

A specific web application where I used MariaDB is a healthcare project where I needed to store user or patient details.

MariaDB has positively impacted our organization in terms of reliability; it has been incredibly stable, and from an operational standpoint, it has drastically improved our deployment workflows since we can run the exact same MariaDB community version locally in Docker containers as we do on our staging and production servers. It has saved us an immense amount of development time, and because it is completely open-source and has excellent documentation, the learning curve was not steep at all.

A solid example of how much development time I have saved using MariaDB is when we were rebuilding our internal inventory tracking tool; it saved us at least two to three weeks of development time because MariaDB worked seamlessly with standard object-relational mappers. We did not have to spend days writing complex, low-level database connection code from scratch, allowing me to focus on mapping our data models directly to the database. Additionally, its query caching and efficient indexing meant we did not need to spend extra time writing custom caching code.

In my experience over the last year, the best features that MariaDB offers include its native JSON data type support and how easy it is to handle indexing. Aside from our main web apps, another minor use case I have worked on involved managing dynamic configuration data and application settings. Because some of our application settings change frequently, being able to store unstructured JSON directly into a column while still using standard SQL functions such as JSON_EXTRACT to query specific keys has saved me from having to constantly alter our database schemas. On top of that, the query optimization tools such as EXPLAIN make it straightforward to figure out exactly where a slow query is getting stuck, allowing me to easily add a proper index to speed up performance.

The key area where MariaDB could be improved is its native GUI tooling; while the command-line interface works perfectly fine, the built-in visual tools for administration, management, and query design feel outdated compared to some competitors. Our team ends up relying on third-party tools such as DBeaver and TablePlus.

A minor thing I can think of would be expanding the online community resources and adding more beginner-friendly video tutorials or interactive sandboxes into the official documentation. Some of its more advanced features take considerable effort to research on Stack Overflow or specialized forums to understand.

I have been using MariaDB for the last one year.

A specific challenge I have faced is troubleshooting performance degradation during heavy write transaction tables; the raw log files with timeout errors were tricky to diagnose because the engine's error logs were not always clear.

For governance and security, keeping AI data inside MariaDB is a huge plus because MariaDB handles AI workloads, such as its native vector search, directly within the relational store database engine rather than spinning up a separate third-party vector database such as Pinecone or Milvus; it makes security governance much tighter. You do not have to worry about securing a brand-new API or managing network sync.

Regarding the output, MariaDB is highly accurate and reliable because it relies on standard, deterministic mathematical vector search rather than guesswork. Since it handles vector storage and similarity searches natively alongside your relational data, I can seamlessly combine precise SQL filters with vector queries, which guarantees that the data retrieved for my AI application is always up-to-date and consistent.

My advice to others looking into using MariaDB would be to dive right in and start playing around with it; the learning curve is very gentle, especially if you already have some SQL background. Do not be afraid to leverage its more advanced features such as JSON support or window functions right away, since that is where you start to see massive productivity gains compared to more traditional relational databases.

MariaDB makes things easy and saves time in the development process. My overall review rating for MariaDB is not applicable.

We are into IoT intrusion systems. Our product is based on building automation systems. We get sensor data from across the regions. We have our own cloud hosted in GCP. The sensor data comes directly to Cassandra. We use MariaDB as a data source for UI purposes. We use a 3-node multi-master architecture using MariaDB Galera Cluster. It is deployed on Kubernetes.

The tool has good scalability and performance. The integration with other products is seamless.

We are facing some deadlock issues when the nodes get rebooted. There is not much support available. The support must be improved. The downtime is more. It takes us time to restore production. There must be less downtime during outages.

I have been using the solution for around six years.

I rate the tool’s stability an eight out of ten. During outages, the recovery time is longer. It takes a lot of time to get the cluster working.

The 3-node architecture is sufficient for our product.

We tried Oracle. It was not affordable. We switched to MariaDB because it is a cost-effective solution.

Everything is automated. Once we deploy the cluster, a 3-node master setup will be ready. The solution is deployed on the cloud.

The tool is open-source.

The solution is very cheap compared to other products like Oracle or SQL Server. We did not compare the tool with PostgreSQL. Some of our customers are planning to move to PostgreSQL. Oracle provides enterprise-level support. SQL Server is backed by Microsoft. MariaDB’s performance and scalability are on par with Oracle and SQL Server.

We had planned for an RDBMS version and not NoSQL. We use MariaDB Galera Cluster. It's a good product. It is cheap, scalable, performs well, and is efficient. We use GCP’s BigQuery for machine learning. We must follow the best practices of the tool.

We missed some best practices like the storage engine and InnoDB. It was very difficult to identify why we were having performance issues. Then, we realized that some of our tables were still on MyISAM, the default storage engine. When we switched it back to the InnoDB, it was very smooth. InnoDB is the recommended one. We must follow the best practices given in the documentation during the initial setup.

Overall, I rate the product a nine out of ten.

I use MariaDB in my company to process the data for the database, so it is just for storage and analytics-related areas.

The most valuable features of the solution stem from the fact that it is a cloud-based tool, so it is pretty fast. The product is also considered to be an SQL-compliant solution.

Document caching is an area of concern in the product, where improvements are required to help MariaDB improve on the previous queries as they are retained, and you can roll back to them.

A cloud-based tool that offers great speed with a need to improve in the area of document caching.

Stability-wise, I rate the solution a ten out of ten.

Scalability-wise, I rate the solution an eight out of ten.

Around 300 people in my company use the solution on a daily basis.

I rate the technical support a five out of ten.

Neutral

There was another solution in our company before MariaDB was introduced. My company moved to MariaDB as it was imposed or forced on us by the vendor named Appian since they prefer MariaDB for databases.

The product's initial setup phase was easy.

The solution is deployed on a public cloud by AWS.

The solution can be deployed in a few hours.

The product's setup phase was taken care of by a third party, Appian.

I have seen a return on investment from the use of the product since it helps my company save time.

I rate the product's price a three on a scale of one to ten, where one is low price, and ten is high price since there are some support costs involved, even though it isn't an open-source solution.

One person, who is the database administrator, is required to maintain the product.

I rate the overall solution a seven out of ten.

The solution is essentially an enterprise application. In our setup, there was a considerable amount of data being utilized. Later, the application shifted to the cloud, and for this cloud migration, we opted for a database switch from Oracle to MariaDB. That's why we migrated all the data and components to MariaDB.

The standout feature is the multitude of features available. There isn't a specific feature that's unavailable in other databases. The key differentiator is the speed. 

When referring to it as a hard code, the core size is crucial. In MariaDB, we can employ multi-processing, allowing users to make use of the core and process data more efficiently and swiftly.

In MariaDB, three aspects can be enhanced, starting with the indexes. Currently, the indexes are not as strong. The second area is related to exclusion queries, subqueries, or joins. There's one join that isn't fully supported, the product I came across about MariaDB.

Customer support can also be improved.

I have been using this solution for four years. 

There have been some issues. If you need to provide 24/7 availability, you have to follow the active-subprivate mode, where one application is active and the second is down. So, other substitute techniques, like mirroring and scrubber techniques, are also available for such scenarios.

It is a scalable solution. It easily scales up and scales down. 

The customer service and support are okay. But the response time is slow. 

Moreover, the material is not available freely.  

Neutral

We have used several databases like MySQL, Oracle, and NoSQL MongoDB. We have tried a number of solutions, so we have that experience.

We switched due to its features. It is a lightweight application, making it the best choice for our lightweight applications.

The initial setup is straightforward. It's not a big deal.

I have deployed it on the cloud, using Linux and everything.  It can be deployed within a day. 

When we were doing the technical evaluation, we considered MariaDB, Finsecure, and AWS cloud databases. Based on that, we made the decision.

Overall, I would rate the solution a five out of ten.

Maria DB is a good product. If any clients want to use MariaDB, I agree with them. The decision to use any software is mostly made by the decision-maker or management. 

As you know, we have better job interactions, and in an enterprise, whether to use MariaDB or another option like MySQL, it's a political decision. I am an architect in the permission system, which follows the policies of this enterprise.

It doesn't have the same level of maturity metrics as Postgres.

For example, if you look at the architecture of Postgres, it has an architecture similar to Oracle, a robust and widely practiced architecture. In terms of multi-database support, both Postgres and MySQL have the same objective. 

Every software, including MariaDB, has its own advantages and features tailored to customer needs. In my opinion, it's a very good solution. I don't have any points to criticize it as a database. We prioritize the needs of our customers and choose from various options accordingly. For instance, MariaDB or MySQL could be suitable options depending on the specific requirements of the project.

In the future release, better management of tablespaces would be beneficial. Currently, it's a bit lacking in that area. Additionally, more efficient space utilization could be improved.

I have only tested it for internet access tools and all the cases for MariaDB, without the enterprise edition.

I am referring to the market ID, Comenity Edition. It is a branch of MySQL and has similar features.

It is a stable solution. 

It is a scalable solution. You know, in my project, I haven't come across any product that was highly scalable.

I have used it for a few months, but I didn't extensively test the scalability of the database. In France, it's not commonly used as a scalable database. In any case, it is one of the databases available, and it can be used with high availability solutions.

The initial setup is very easy. 

It is free of charge. I didn't use the paid version. 

Maria DB offers various advantages over its competitors. It offers the ability to simultaneously use active server capabilities. This feature is very attractive for this type of solution.

If someone asked me about MariaDB, I would say that it is easy to implement and stable. However, it lacks a significant number of experts in the market compared to Postgres. Integration can also be a challenge.

I would rate Maria DB a seven out of ten. 

We mostly use MariaDB on smaller systems, not for mission critical systems. For mission critical systems, we use Oracle.

We're using version 10.5. The solution is deployed on-premises.

We're a very centralized operation. We install the system on an application, the application runs the services, and people consume those services. We have three systems running this on the database.

The cost is much lower than other solutions, especially if you look at the functionality compared to MySQL.

The speed and functionality are the most valuable features. Compared to other solutions, there is more value and functionality for the cost. 

The replication is much easier, and I like the administrative portal.

An improvement would be scaling it up to the levels of Oracle, especially when it comes to resilience, so that we can do higher transactions for two databases or power our operation. When it comes to higher availability, that's where it gets more complicated. I think the system needs to be more mature, especially for enterprises.

They could improve the replication rate. I know the connection pool goes up to 20,000 connections. It should be more accessible.

The interface and integration could also be improved.

I have used MariaDB for over one year.

The solution can run for months without any issues.

I would rate the stability as 8 out of 10.

The scalability improves if you use the distributed database. In our case, the performance has been good enough for the applications we use. We haven't had any performance issues to warrant improving it beyond one node. We moved the storage to SSD, so the performance is good from a basic setup.

I would rate the scalability as eight out of ten. It's a little bit complex.

We haven't needed to resort to technical support. Most of the time, we look at the documentation, and we're able to work out things on our own.

I have also used MySQL. When Oracle purchased MySQL, it was split into two options: the official version and the open source version. We started having a divergence in the updates, and then the open source version got left behind. We thought it was too caught up in a big enterprise and it wouldn't get the same attention. It was probably stifled because it was going to create competition for Oracle. We thought that maybe MariaDB was catching up fast, getting more features, and improving much faster than MySQL.

Initial setup is very easy. If you're used to MySQL, it's easy, but things get a little bit complex when you're setting up replication. We can get the solution running in less than an hour.

Implementation was done in-house. We required one person for deployment. They are a database administrator.

One person is needed for maintenance. It's a very economical system. Once you get it up and running, there's very little maintenance needed.

You just need to monitor it and see if the IO performance is good. If anything, you have to optimize your queries.

I would rate the setup as nine out of ten.

The cost is quite good. You can have the open source, free version, which has adequate capacity. Compared to Oracle, MariaDB has a more flexible policy and less officials. Oracle is too big of an organization, and they do certain things that leave a sour taste in our mouth. Dealing with a smaller company is sometimes better, especially for smaller systems.

I would rate the licensing cost as nine out of 10.

We also evaluated PostgreSQL.

With our experience with MySQL, we thought we needed to convert most of the queries to PostgreSQL. MariaDB was much closer to MySQL than to PostgreSQL, and PostgreSQL hasn't moved quickly enough compared to MariaDB.

PostgreSQL is quite high end, but there were differences in the syntax of the scale. We didn't want to be involved in converting the syntax.

I would rate this solution as nine out of ten. 

It has a lower cost of ownership, and you need less effort to get it up and running. There's less effort in getting to know the system compared to other database systems. I would encourage people to move to it, especially if they've already used MySQL.

We use MariaDB for small and middle-sized applications of all kinds. It is primarily used for database operations and functions as a database server.

We use some asynchronous master-slave implementations and synchronous multi-master Galera setups.

The only potential area for improvement could be the pricing model, which might benefit from being more flexible or a bit cheaper.

I have been working with MariaDB for five years.

MariaDB is very stable. I would rate its stability a nine out of ten.

MariaDB is fine for small and middle-sized databases. However, for very large environments, I would hesitate as I don't think that MariaDB is limitless scalable. There is a decisive difference between MariaDB and larger databases like Oracle.

The initial setup of MariaDB is simple enough.

My colleagues or I usually do the setup. We install and configure everything, and once it's running, the client takes over with the application setup.

I have found the price of commercial MariaDB to be pretty steep, although not as high as Oracle. Customers often prefer the Community Edition because it's free.

MariaDB's main competitors are MySQL, Oracle, and Postgres. I think Postgres is the sharpest competitor to MariaDB.

I would fully recommend MariaDB. It is stable, performs well, and is relatively easy to handle. Overall, it has good basic functionality.

I'd rate the solution eight out of ten.

MariaDB is used like any other relational database where we need complex join queries as well as tasks like read and write using the tool. The tool also offers support in terms of sharding, which is why we use MariaDB. Every time we use the tool, we have some kind of a reason, or, I would say, a requirement of asset compliance, which is atomicity, consistency, isolation, and durability, which is only provided by a relational database. Companies usually go towards open-source databases. Oracle is very costly. Oracle is not an open-source tool, which is why people tend to go towards open-source. The databases are doing pretty well in different applications.

A well-known issue for a lot of different users is associated with write-intensive applications. There are so many write-intensive applications. Usually, the applications are designed as read-intensive ones, where the number of reads is way more than the write operations. I would say MariaDB or any other relational database is designed by default to be for read-intensive applications. There are a lot of features being added to the tool, such as something called Galera Cluster, which supports write-intensive applications and sharding. People have to come up with their own way to share their applications, and that is the only way they can come up with a better performance tool for write-intensive applications.

I have been using MariaDB for two years. I am not a customer of the product, but my company does cater to the needs of multiple customers. My company uses the tool at work, and it is a part of our product.

As a part of the NDA, I cannot discuss the number of users of the product since it is a public company, but I can say that we have thousands and thousands of customers, and every one of them has products that are on their own databases.

The technical side of the solution is there, and they have been doing this for a very long time. The solution's technical support team is responsive. I rate the technical support an eight out of ten.

Positive

I work with MariaDB and PostgreSQL.

The product's initial setup phase was not at all challenging, and the reason for that is there is so much community support. You could face any issues which are not properly discussed in the community. Almost every issue has been discussed in the community, so there is no way you could be stuck somewhere, and you are trying to figure out what you can do next since it will not happen when you use MariaDB.

The solution is deployed on a hybrid cloud model.

The community support offered by the product is good. There is one specific thing about community support, and it is that it doesn't matter if it is a relational database or any other code that is public and open source. If it is open-source, the tool gets enhanced multiple times in a better way because every company has its own requirements. As per the requirement, people are merging codes in the main branch, and I am specifically talking about GitHub for now. MariaDB has so much flexibility and features, like data compression, audit plugins, and tablespace encryption, and it supports discrete encryption. Because of the tool's community support, it has varied functions and can be used almost anywhere or wherever you want as a relational database.

In terms of data management efficiency, I would say that it is pretty efficient. The tool is simpler to support if you talk from an engineer's perspective, and it is easier to provide any assistance to the customer who needs some kind of data from their product. The tool provides its own high availability, which means a 99.99 percent high availability. The biggest thing about the tool is that it is an open-source product, and it is supported by a community, which is pretty nice, especially because the community improves the product pretty well. If the product was available at a certain price, there are very few requirements in such scenarios. For open-source products, there are multiple requirements, so the product is enhanced way faster, and that is why people prefer an open-source tool. MariaDB or MySQL are some of the most used relational databases.

It is not very complicated to maintain the tool.

I rate the tool an eight out of ten.