Using MySQL and Mongodb together

Question

I have worked with MySQL more than MongoDB, but from what I've learned from MongoDB it's just what I needed, but it also has it's limitations that MySQL can do (for instance auto increment)

Would it be smart to use MongoDB for everything, and use MySQL for only certain things?

For instance use MongoDB to store users and everything else, but use MySQL to make for example a ticket system.

Intervocalic

It would depend on the job. For example, Auto-Increment is not a good enough reason for me to add another db. But there's nothing basically wrong about having two different dbs if you need them. – Fusillade

Yea I'm using it for more than just that, I was just giving an example. Thanks. – Intervocalic

Answer 1

It sounds perfectly reasonable to use two database technologies in one project. Just make sure you use the right tool for the job.

It's common to use MySQL as the primary storage and MongoDB as caching/intermediate storage for speed.

You can for example have read-intensive data in MongoDB. The data for generating reports is perfect for a relational system like MySQL.

Melaniamelanic

Is it common to use two different databases? – Intervocalic

Two different kind of database, for example an Object oriented and an a Relational one ... – Heavyhearted

Thanks, I now learned that I should be using MySQL as my main database, and use MongoDB for other things, I'll start converting my application :) (don't worry it's small) – Intervocalic

Answer 2

There is a pretty good discussion of Use Cases for MongoDB on the main MongoDB site. In general, if your business case includes the need for transactions and heavy T-SQL functionality, then you'd be better served by using a RDBMS such as MySQL.

Good Use Cases for MongoDB are as follows:

1. Your data is in a document format, i.e. irregular structure in single documents (that is data doesn't need to be joined)
2. You are considering using a flat file system (again due to the structure of your data), but you would like 'more' in terms of ability to index/query that data.
3. Your project is in a state where you genuinely don't know what the schema or structure of your data will ultimately be.
4. You have specialized data types, such as geo-spatial data, and you want to be able to query against it.
5. You may have a need to quickly and cheaply scale your data storage location.

Honesty

Just want to say point 3 isn't necessarily a good use case for Mongo.. I'd say MySQL would be much better in that situation. Although if you have no idea what your database needs to look like you shouldn't start developing your project until you do. – Tung

@JohnHarding is not that simple. I found myself in a project where the model cannot be fully described, and requires constant updates. In this case i found Mongo much easier to work with. – Devin

My real case scenario is a dashboard / reports intranet that fetches data from several vendors. We update our own database with scheduled crons jobs. There is little intersection among those "modules". The performance difference has been negligible to us but our services / models / repositories based on mongoose are 3x smaller than those with TypeOrm. Let alone handling migrations. – Puzzle

Answer 3

Here is a well-typed discussion of mongodb usage, by someone who took mongoDb courses

Considerations for choosing or not choosing MongoDB

The blogger mainly says that using mongodb with other DB systems is perfectly fine , yet using it system wide , can be most challenging and almost impossible at some certain scenarios.

Here are some subtitles :

Reasons to choose Mongo

• Document oriented and schemaless
• Horizontal Scalability and High Availability
• Fast writes in the fire-and-forget mode
• Comprehensive Querying and Aggregation Framework
• Comparatively intuitive architecture

Reasons not to choose Mongo

• No SQL = No Joins
• No ACID transactions
• Your indexes would not fit into memory

Wornout

Just to add an update to the answer, ACID transaction available from mongo 4.0 onwards. – Achievement