27

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.

WittyPleb
  • 553
  • 2
  • 10
  • 22
  • 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. – joshp May 20 '12 at 19:22
  • Yea I'm using it for more than just that, I was just giving an example. Thanks. – WittyPleb May 20 '12 at 19:24

3 Answers3

25

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.

ilanco
  • 9,581
  • 4
  • 32
  • 37
  • Is it common to use two different databases? – WittyPleb May 20 '12 at 19:19
  • Two different kind of database, for example an Object oriented and an a Relational one ... – aleroot May 20 '12 at 19:21
  • 1
    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) – WittyPleb May 20 '12 at 19:28
8

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.
Erme Schultz
  • 319
  • 5
  • 17
Lynn Langit
  • 4,030
  • 1
  • 23
  • 31
  • 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. – John Harding Dec 21 '16 at 19:39
  • @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. – Wanny Miarelli Feb 20 '18 at 19:17
  • 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. – José Henrique Aug 08 '22 at 02:25
8

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
cemclaug
  • 35
  • 1
  • 8
kommradHomer
  • 4,127
  • 5
  • 51
  • 68