Need advice about which tool to choose?Ask the StackShare community!
MariaDB vs Microsoft SQL Server: What are the differences?
Introduction:
MariaDB and Microsoft SQL Server are both popular database management systems used in various applications and websites. While they share similarities as relational database management systems (RDBMS), there are key differences between the two.
Storage Engine Support: One major difference is the storage engine support. MariaDB supports a wide range of storage engines, including InnoDB, MyISAM, and Aria, among others. On the other hand, Microsoft SQL Server uses a single storage engine, known as the SQL Server Storage Engine. This difference gives MariaDB more flexibility in terms of choosing the most suitable storage engine for specific use cases.
Licensing: Another significant difference between MariaDB and Microsoft SQL Server is the licensing. MariaDB is released under the GNU General Public License (GPL), which means it is free and open-source software. In contrast, Microsoft SQL Server is a proprietary software product that requires a commercial license for use. This distinction makes MariaDB more accessible and cost-effective for organizations with limited resources or a preference for open-source solutions.
Platform Compatibility: MariaDB is known for its cross-platform compatibility, as it can be installed and used on various operating systems, including Windows, Linux, and macOS. On the other hand, Microsoft SQL Server is primarily designed for Windows-based systems, although there have been recent developments to support Linux installations. This difference in platform compatibility gives MariaDB an advantage for organizations using different operating systems.
Administration Tools: MariaDB and Microsoft SQL Server offer different administration tools for managing and monitoring databases. MariaDB uses tools such as MySQL Workbench and phpMyAdmin, which provide a web-based interface for performing database administration tasks. In contrast, Microsoft SQL Server includes tools like SQL Server Management Studio (SSMS) that offer a comprehensive set of features for database management. These differences in administration tools can affect the user experience and the familiarity of database administrators.
Replication: Replication is a crucial feature for maintaining high availability and data redundancy in distributed systems. MariaDB and Microsoft SQL Server differ in their replication capabilities. MariaDB supports multiple types of replication, such as master-slave and master-master replication, allowing for flexible and scalable replication setups. In comparison, Microsoft SQL Server offers transactional replication and merge replication, which have different characteristics and limitations. This difference may impact the choice of database management system for applications requiring robust replication capabilities.
Community and Support: Both MariaDB and Microsoft SQL Server have active communities and support resources. However, as an open-source project, MariaDB benefits from a larger community of developers and contributors who provide extensive support through forums, documentation, and online resources. Microsoft SQL Server, being a proprietary software, offers support through official channels, such as online documentation, forums, and paid support options. The difference in community and support resources may influence the level of assistance and availability of solutions when facing issues or challenges.
In Summary, MariaDB and Microsoft SQL Server differ in storage engine support, licensing, platform compatibility, administration tools, replication capabilities, and community and support resources. These differences make MariaDB a more flexible, cost-effective, and cross-platform option, while Microsoft SQL Server provides comprehensive tools and support options but is limited to Windows-based systems.
I have a project (in production) that a part of it is generating HTML from JSON object normally we use Microsoft SQL Server only as our main database. but when it comes to this part some team members suggest working with a NoSQL database as we are going to handle JSON data for both retrieval and querying. others replied that will add complexity and we will lose SQL Servers' Unit Of Work which will break the Atomic behavior, and they suggest to continue working with SQL Server since it supports working with JSON. If you have practical experience using JSON with SQL Server, kindly share your feedback.
I agree with the advice you have been given to stick with SQL Server. If you are on the latest SQL Server version you can query inside the JSON field. You should set up a test database with a JSON field and try some queries. Once you understand it and can demonstrate it, show it to the other developers that are suggesting MongoDB. Once they see it working with their own eyes they may drop their position of Mongo over SQL. I would only seriously consider MongoDB if there was no other SQL requirements. I wouldn't do both. I'd be all SQL or all Mongo.
I think the key thing to look for is what kind of queries you're expecting to do on that JSON and how stable that data is going to be. (And if you actually need to store the data as JSON; it's generally pretty inexpensive to generate a JSON object)
MongoDB gets rid of the relational aspect of data in favor of data being very fluid in structure.
So if your JSON is going to vary a lot/is unpredictable/will change over time and you need to run queries efficiently like 'records where the field x exists and its value is higher than 3', that's a great use case for MongoDB.
It's hard to solve this in a standard relational model: Indexing on a single column that has wildly different values is pretty much impossible to do efficiently; and pulling out the data in its own columns is hard because it's hard to predict how many columns you'd have or what their datatypes would be. If this sounds like your predicament, 100% go for MongoDB.
If this is always going to be more or less the same JSON and the fields are going to be predictably the same, then the fact that it's JSON doesn't particularly matter much. Your indexes are going to approach it similar to a long string.
If the queried fields are very predictable, you should probably consider storing the fields as separate columns to have better querying capabilities. Ie if you have {"x":1, "y":2}, {"x":5, "y":6}, {"x":9, "y":0} - just make a table with an x and y column and generate the JSON. The CPU hit is worth it compared to the querying capabilities.
Hi all. I am an informatics student, and I need to realise a simple website for my friend. I am planning to realise the website using Node.js and Mongoose, since I have already done a project using these technologies. I also know SQL, and I have used PostgreSQL and MySQL previously.
The website will show a possible travel destination and local transportation. The database is used to store information about traveling, so only admin will manage the content (especially photos). While clients will see the content uploaded by the admin. I am planning to use Mongoose because it is very simple and efficient for this project. Please give me your opinion about this choice.
The use case you are describing would benefit from a self-hosted headless CMS like contentful. You can also go for Strapi with a database of your choice but here you would have to host Strapi and the underlying database (if not using SQLite) yourself. If you want to use Strapi, you can ease your work by using something like PlanetSCaleDB as the backing database for Strapi.
Your requirements seem nothing special. on the other hand, MongoDB is commonly used with Node. you could use Mongo without defining a Schema, does it give you any benefits? Also, note that development speed matters. In most cases RDBMS are the best choice, Learn and use Postgres for life!
MongoDB and Mongoose are commonly used with Node.js and the use case doesn't seem to be requiring any special considerations as of now. However using MongoDB now will allow you to easily expand and modify your use case in future.
If not MongoDB, then my second choice will be PostgreSQL. It's a generic purpose database with jsonb support (if you need it) and lots of resources online. Nobody was fired for choosing PostgreSQL.
SQL is not so good at query lat long out of the box. you might need to use additional tools for that like UTM coordinates or Uber's H3.
If you use mongoDB, it support 2d coordinate query out of the box.
Any database will be a great choice for your app, which is less of a technical challenge and more about great content. Go for it, the geographical search features maybe be actually handy for you.
Any database engine should work well but I vote for Postgres because of PostGIS extension that may be handy for travel related site. There's nothing special about your requirements.
Hi, Maxim! Most likely, the site is almost ready. But we would like to share our development with you. https://falcon.web-automation.ru/ This is a constructor for web application. With it, you can create almost any site with different roles which have different levels of access to information and different functionality. The platform is managed via sql. knowing sql, you will be able to change the business logic as necessary and during further project maintenance. We will be glad to hear your feedback about the platform.
I am a Microsoft SQL Server programmer who is a bit out of practice. I have been asked to assist on a new project. The overall purpose is to organize a large number of recordings so that they can be searched. I have an enormous music library but my songs are several hours long. I need to include things like time, date and location of the recording. I don't have a problem with the general database design. I have two primary questions:
- I need to use either MySQL or PostgreSQL on a Linux based OS. Which would be better for this application?
- I have not dealt with a sound based data type before. How do I store that and put it in a table? Thank you.
Hi Erin,
Honestly both databases will do the job just fine. I personally prefer Postgres.
Much more important is how you store the audio. While you could technically use a blob type column, it's really not ideal to be storing audio files which are "several hours long" in a database row. Instead consider storing the audio files in an object store (hosted options include backblaze b2 or aws s3) and persisting the key (which references that object) in your database column.
Hi Erin, Chances are you would want to store the files in a blob type. Both MySQL and Postgres support this. Can you explain a little more about your need to store the files in the database? I may be more effective to store the files on a file system or something like S3. To answer your qustion based on what you are descibing I would slighly lean towards PostgreSQL since it tends to be a little better on the data warehousing side.
Hey Erin! I would recommend checking out Directus before you start work on building your own app for them. I just stumbled upon it, and so far extremely happy with the functionalities. If your client is just looking for a simple web app for their own data, then Directus may be a great option. It offers "database mirroring", so that you can connect it to any database and set up functionality around it!
Hi Erin! First of all, you'd probably want to go with a managed service. Don't spin up your own MySQL installation on your own Linux box. If you are on AWS, thet have different offerings for database services. Standard RDS vs. Aurora. Aurora would be my preferred choice given the benefits it offers, storage optimizations it comes with... etc. Such managed services easily allow you to apply new security patches and upgrades, set up backups, replication... etc. Doing this on your own would either be risky, inefficient, or you might just give up. As far as which database to chose, you'll have the choice between Postgresql, MySQL, Maria DB, SQL Server... etc. I personally would recommend MySQL (latest version available), as the official tooling for it (MySQL Workbench) is great, stable, and moreover free. Other database services exist, I'd recommend you also explore Dynamo DB.
Regardless, you'd certainly only keep high-level records, meta data in Database, and the actual files, most-likely in S3, so that you can keep all options open in terms of what you'll do with them.
Hi Erin,
- Coming from "Big" DB engines, such as Oracle or MSSQL, go for PostgreSQL. You'll get all the features you need with PostgreSQL.
- Your case seems to point to a "NoSQL" or Document Database use case. Since you get covered on this with PostgreSQL which achieves excellent performances on JSON based objects, this is a second reason to choose PostgreSQL. MongoDB might be an excellent option as well if you need "sharding" and excellent map-reduce mechanisms for very massive data sets. You really should investigate the NoSQL option for your use case.
- Starting with AWS Aurora is an excellent advise. since "vendor lock-in" is limited, but I did not check for JSON based object / NoSQL features.
- If you stick to Linux server, the PostgreSQL or MySQL provided with your distribution are straightforward to install (i.e. apt install postgresql). For PostgreSQL, make sure you're comfortable with the pg_hba.conf, especially for IP restrictions & accesses.
Regards,
I recommend Postgres as well. Superior performance overall and a more robust architecture.
Easy to start, lightweight and open source.
When I started with PHP, MySQL was everywhere so this is how I started with it. I am no expert in databases but I started learning joins, stored procedures, triggers, etc. with MySQL.
Recently used it in one of my projects - Picfam.com with Node.js + Express backend
Needed to transform intranet desktop application to the web-based one, as mid-term project. My choice was to use Django/Angular stack - Django since it, in conjunction with Python, enabled rapid development, an Angular since it was stable and enterprise-level framework. Deadlines were somewhat tight since the project to migrate was being developed for several years and had a lot of domain knowledge integrated into it. Definitely was good decision, since deadlines was manageable, juniors were able to enter the project very quickly and we were able to continuously deploy very well.
We actually use both Mongo and SQL databases in production. Mongo excels in both speed and developer friendliness when it comes to geospatial data and queries on the geospatial data, but we also like ACID compliance hence most of our other data (except on-site logs) are stored in a SQL Database (MariaDB for now)
Pros of MariaDB
- Drop-in mysql replacement149
- Great performance100
- Open source74
- Free55
- Easy setup44
- Easy and fast15
- Lead developer is "monty" widenius the founder of mysql14
- Also an aws rds service6
- Consistent and robust4
- Learning curve easy4
- Native JSON Support / Dynamic Columns2
- Real Multi Threaded queries on a table/db1
Pros of Microsoft SQL Server
- Reliable and easy to use139
- High performance101
- Great with .net95
- Works well with .net65
- Easy to maintain56
- Azure support21
- Full Index Support17
- Always on17
- Enterprise manager is fantastic10
- In-Memory OLTP Engine9
- Security is forefront2
- Easy to setup and configure2
- Docker Delivery1
- Columnstore indexes1
- Great documentation1
- Faster Than Oracle1
- Decent management tools1
Sign up to add or upvote prosMake informed product decisions
Cons of MariaDB
Cons of Microsoft SQL Server
- Expensive Licensing4
- Microsoft2