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.

It's a relational database, so it's mainly used for structured data. We use it for some of our in-house applications.

For us the benefit is that the system is very stable, so we don't have many outages. We also have a lot of experience with MariaDB, so we can optimally configure MariaDB and deploy a well-tuned environment.

I like the global transaction IDs (GTIDs) feature. It's quite reliable for replication between a master and a replica server, and it's a feature that MySQL also has but implemented differently. 

Another thing I like is the flashback feature, which allows you to roll back a transaction from the binary logs, so you can retrieve data. If someone deleted data, you can flash it back. That's a feature I really appreciate.

I'm interested in witnessing the integration of materialized views, which would enable the preservation of select queries. This particular functionality seems to be absent in MariaDB when compared to rival relational databases such as Oracle and SQL Server. The inclusion of this feature, akin to the offering from PostgreSQL, would be a valuable addition to MariaDB's capabilities.

I have nearly 13 years of experience working extensively with MySQL, and in recent years, I've also gained proficiency with MariaDB. Since MariaDB is closely related to MySQL, my combined experience with both platforms spans over a decade. Currently, we're utilizing version 10.4, although it's a few iterations behind the most recent release. We're actively preparing to undertake an upgrade in the near future.

It is a quite stable solution. 

If you want to scale it for larger use cases, like sharding, you'd need to consider MariaDB SkySQL or Xpand, which is a separate product designed for cloud deployments. So, for realistic scalability, especially in the cloud, you might need to use MariaDB SkySQL.

We have a couple of hundred users currently working with the database. It's probably around 400.

It's currently deployed on-premises, but we're planning to move it to the cloud in the future.

It's not difficult to maintain. It does require some maintenance, but it's very stable. You don't really need to intervene much, so it's quite stable. The main maintenance we do is patching and upgrading once a year. So it's not too taxing to maintain.

I have used MySQL or Oracle products. 

MariaDB, being open source, is a significant advantage, especially considering we use the enterprise edition. It's considerably much cheaper than Oracle, which is a proprietary database with high licensing costs. So, from a financial perspective, MariaDB is far more economical. 

Another advantage lies in its robust online community, simplifying troubleshooting and assistance. While we do have enterprise support, the online community and resources are quite valuable. 

As for cons, due to fewer contributors compared to other databases like MariaDB, certain features might experience slower development. Amazon and MariaDB Corporation are among the contributors, but it's an area that could use more attention. However, overall, MariaDB remains a strong choice.

MariaDB emerged as a distinct entity originating from MySQL, rather than being an inherent part of it. Formed in 2009 due to apprehensions that Oracle Corporation might negatively impact MySQL, which they acquired in 2010.

When deciding between MySQL and MariaDB, the feature disparity is minimal. MySQL has adeptly upheld compatibility since the transition, making it primarily a matter of personal preference. Some features differ between MariaDB and MySQL, catering to unique preferences.

In essence, MariaDB is a highly favored relational database, a commendable choice within the relational database realm. For those seeking a relational database, MariaDB stands as a solid option. As for purchasing a database, MariaDB comes highly recommended. It claims the second-highest rank globally and holds the second spot in the DB-Engines ranking. MongoDB ranks a bit lower, but the choice between the two is essentially equivalent.

On the whole, I would assign a rating of seven out of ten to this solution.

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.

In my work with ServiceNow, customer instances typically use MariaDB databases. As a performance engineer and tester, I focus on the application's performance and ensure its smooth integration with MariaDB. This means I'm responsible for identifying and troubleshooting any performance issues that might arise.

A relational database like MariaDB offers several advantages, including faster query execution and improved login security. Having evaluated other options like MySQL, I find MariaDB's strengths align perfectly with my specific database needs. 

MariaDB is known for its user-friendly interface and excels in specific performance areas. It delivers fast processing times, particularly for frequent select queries and insert/update operations.

While MariaDB is a good relational database, it can be inflexible for complex use cases. It doesn't adapt well to changing needs and lacks features like time series data support, which requires us to use ServiceNow's Clotho DB. In short, MariaDB's strength lies in its core functionality but it is not suitable for all situations.

While MariaDB itself doesn't offer built-in analytics tools, ServiceNow provides Stats Now for internal data visualization. This tool integrates with other analytics platforms like Splunk or Grafana, all pulling data from the same central source. MariaDB likely avoids including its own analytics due to these existing solutions within ServiceNow.

I have been using MariaDB for two years.

I would rate the stability of MariaDB eight out of ten. Certain queries can be slow but overall MariaDB is stable.

As a relational database, MariaDB inherits the advantages and disadvantages of this category, but it also offers easy scalability. We can add more nodes to the database cluster as needed to handle growing data and user demands. Additionally, MariaDB allows for the creation of backups to ensure data security and simplifies the scaling process itself.

MariaDB's initial deployment was smooth thanks to our extensive automation within ServiceNow. While data fetching hasn't been thoroughly tested yet, overall the process has been positive.

The deployment can take anywhere from one to seven days because MariaDB takes time to clone.

Between MariaDB and Oracle, I find Oracle is better because it provides a lot more information and is more comfortable to work with.

I would rate MariaDB eight out of ten.

MariaDB excels for well-defined tasks involving specific data sets. However, it might not be ideal for highly dynamic situations requiring frequent exploration and manipulation of large, diverse data volumes. 

For various applications, we use MariaDB as a database to test the incoming and outgoing data for any application. 

We check the relational database, how it's working, how the data is organized, how the queries have been written, and how we can streamline or improve the performance of these stored procedures. 

These are the things we look for to maintain a good relationship between the front end and the back end of the system.

One of the great features of MariaDB is its scalability. It's easy to handle even with large databases. 

It's also user-friendly and allows you to create complex relationships with the data. It means you can fetch data from multiple correlated or related databases in a single query. So it allows complex relationships with specific databases.

MariaDB supports SQL, and it has an advantage over regular SQL in that it is a lighter version. Even with huge amounts of data, it performs well.

MariaDB is everything that SQL DB has, but it's much lighter and more flexible. It's also more expandable. So I don't think MariaDB has any disadvantages compared to SQL DB.

So the only issue is that it's not as lightweight as SQL DB. That's probably the only drawback.

In future releases, mainly the addition of security features would be beneficial for MariaDB. It would be great to have built-in capabilities that can be managed through plug-ins and system administration. This would require incorporating security measures into the code, which is a one-time activity but needs to be maintained. Wrappers can also be written for reusability and improved security. That's something MariaDB could benefit from.

Since I've been in my current company, we have used Microsoft SQL Server (MSSQL) as the database since the beginning. And then there's MariaDB.

Additionally, we also use Oracle in some specific projects.

Sometimes any system may have occasional issues, but overall, we are not facing significant problems. We used to face more issues in the early stages.

Overall, I would rate the stability a nine out of ten. 

MariaDB is quite easy to maintain. It's scalable and maintainable. Since it's Knox, directly or indirectly, around 40,000 people would be using it.

We have an in-house team to maintain MariaDB, so we don't require much external support.

I've worked with Oracle for one and a half years. Currently, I'm working with MariaDB and SQL DB.

I worked with Oracle DB before. Currently, I am not working with Oracle DB. Oracle is much more secure, but it is also costlier. 

With MariaDB, you have to be proactive. The security team and the design team need to be vigilant to ensure sufficient security measures. On the other hand, Oracle comes with security features included in the package, which is a major advantage. 

MariaDB is quite easy to install.

Deployment time depends on the level of application and the size of the database. For example, installing MariaDB from scratch may take some time due to design and architectural issues. 

However, if the DB is already available and you need to install it on your system, it doesn't take much time. It usually takes only one or two days, depending on the support you receive from the server side.

So, the number of people required for the deployment depends on the systems and the project. The magnitude of the database also plays a role. 

Since it's not a centralized database and specific to various systems, I would say for Knox, where we also use MariaDB in a large-scale system, there are more than 50 people involved in the design and database aspects out of a team of a thousand people.

And as for architects, there would be fewer. There are six to seven architects because there are different systems for nodes, meetings, Knox Mail, and Knox Client teams. So each specific system may have a dedicated architect.

MariaDB is relatively cheap. It is very cost-effective.

My advice would be, if you can handle the security aspect, MariaDB is a lightweight, scalable, and maintainable database that can be used for both small and large applications.

On a scale of one to ten, I would rate it nine. Due to its cost-effectiveness, scalability, and flexibility, I find it highly commendable.

Around 90 percent of our clients are using MariaDB.

My company sells, implements, and supports ERP systems, and our particular ERP offering runs on MariaDB.

Our ERP solution runs on MariaDB by default. The second database that MariaDB also supports is not a tool we actively promote, but some of our clients prefer it and it is known as PostgreSQL.

The most valuable feature of the solution is the query speed it offers. It can really process queries, and essentially, every field that you add to a table is automatically indexed and can be queried.

The ability to create stored procedures in MariaDB is an area where the tool lacks a bit. It is an area where improvements are required. MariaDB is not as powerful as Microsoft SQL Server, which is a tool that I don't use because, in my opinion, putting a processing load on the database is not a good architecture.

I have been using MariaDB since 2018. My company has a partnership with MariaDB.

MariaDB is open-source and free to use. We do not need external support when we can support ourselves in terms of the technicalities surrounding its use or even help our clients who use it.

I actually use MariaDB, and I used PeerSpot's website to search for and compare the performance between MariaDB and MySQL for our company's marketing efforts. Now, we are pushing MariaDB in our company.

Over PostgreSQL, I can say MariaDB is comparatively easier to use. PostgreSQL is ideal for larger datasets as the processing works faster. The hardware requirements for PostgreSQL are slightly higher than those for MariaDB, which means our hosting services will incur more costs if we use it. MariaDB and PostgreSQL are more or less the same. PostgreSQL is slightly more scalable than MariaDB. There are some tech people who, because of even that small margin, even if they are really not going to be maximizing the power behind PostgreSQL fields, believe that it will work better for them.

My company helps the customers implement the product.

I have had no problems configuring the tool. There was one highly technical problem I had with it, but I have found a solution for it.

MariaDB is available for free.

In terms of AI or machine learning, we are actually developing predictive AI capabilities using MariaDB. Essentially, we have segmented our market into small, medium, and large. The data model we need for small is okay, so using MariaDB for small to medium businesses is fine. For large businesses, we prefer to go with MongoDB.

It is not my department to look into the AI part. We have our company's own AI labs, but it is not under my control. There are a couple of AI projects, but I am not completely aware of the details of the projects that my company's team is working on currently.

It can impact the operational costs of our customers compared to other databases. The tool obviously lowers the customer's total cost of ownership of the software because they don't need to pay a separate fee for the database.

My company doesn't offer that we don't charge separately for the database. It is really transparent to the end user to the client. When it comes to the cost of the database, it is free. We charge if our customers prefer it because it has a configurable option whether they want to keep the application server and the database server separate. If they want a separate database server, then we charge for the server but not for the database.

I recommend the tool to others. The main and primary reason why I even encountered PeerSpot website is to look for information and find data that will support my claim that MariaDB is as good or even better than some database solutions out there.

I rate the tool an eight or nine out of ten.

We use MariaDB for any instance where we need faster retrieval and processing rates, such as establishing relationships between data entities through entity relationship mapping. MariaDB is our preference for structured data, like user details or product information. However, for handling non-structured data, such as metadata, we prefer DynamoDB or MongoDB.

MariaDB is inherently faster than MySQL database. However, given the opportunity, our team would have likely chosen Postgres for better performance in terms of concurrency, etc.

MariaDB is likely less resource-intensive than Postgres and other RDMS solutions because it offers only a subset of features.

Concurrency is a challenge in MariaDB.

I have been using MariaDB for a year.

Ten engineers are using this solution.

It's open source, but there are no dedicated technical support resources.

The deployment should be easier because we use AWS EC2 instances to run and deploy the image and the services. It took a few hours to complete.

It's an open-source solution that only charges for a server database.

I rate the solution's pricing an eight or nine out of ten, where one is expensive, and ten is cheap.

A few EC2 instances are running that solve the MySQL and the service. 

Cross-functional GUIs are currently available. For example, we use DB Workbench, a solution that provides a GUI interface for MySQL, PostgreSQL, MariaDB, and several other databases.

It is seamless unless we want more advanced features, like simple database charting or event scheduling, which MariaDB doesn't support.

Our security team and platform team maintain security features. So, it depends on the type of protocols they use.

There are no particular challenges because the development kit, such as all the SD cases that are DB connectors, is well supported by Python and Java.

Our AI projects' data comes from non-relational sources like Mongo and Dynamo. Therefore, there's no direct correlation. However, MariaDB merely serves as a repository for information, such as profile data or some form of structured text (NTT), which can be displayed in tables or otherwise.

It depends on whether they prioritize performance and features. If so, they might prefer Postgres. However, MariaDB could be the better choice if they prioritize a time-tested solution and lower costs.

MariaDB offers more features than its competitors. It supports features like sharding and concurrent connections.

Overall, I rate the solution an eight out of ten.