Can I use two different databases in one single node app?

Can I use two different databases in one single node app?
0

#1

Hi all, I am currently working on a school management software using node and I want to integrate two different databases in the same node app. It is an express app with a mongodb database. Is this possible?


#2

I think it may be helpful to indicate what kind of database you are using/intend to use! :slight_smile:


#3

Sorry boss, it is mongodb.


#4

I haven’t tried it before but SO seems to suggest that it’s not an issue (link)!


#5

You might need to create separate database handlers but it shouldn’t be an issue.


#6

Of course. You can set up multiple database connections in your project.


#7

To be clear, are you asking about using two different database management systems (Mongo and Postgres/Redis/MySQL), or just two separate databases in the same system (one DB for Users and another DB for classes, both in Mongo)? It’s not uncommon to use more than one DBMS, but it’s important to have a good reason for making that choice.


#8

I’m developing a school management system using nodeJs, express and mongodb. The school has two different branches in different locations. I need to utilize two different databases for the two different branches to avoid conflicts. I am still thinking of ways of implementing this.


#9

I am not sure what you mean by avoiding conflicts, but I am sure you could structure your database in such a way to still have access/modify data for two different branches in the same single DB.


#10

You have options. The easiest is to just have the schools use different instances of your app on separate servers. Completely different computers means different databases. This may not be possible, depending on what your school wants out of this app. If you’re limited to a single server, I would suggest you use a field in your database entries for the school’s branch. Then, you would be able to find the students for BranchA by connecting to the students table and searching for documents with the correct branch entry:

db.students.find({"branch": "BranchA"})
    .toArray(function(err, students) {
        //...
    })

Of course, your actual queries will probably be more detailed (and you’ll hopefully be using Mongoose), but that’s the gist. What you do not want to do is hard code in separate databases for each branch.


#11

I’m looking for information on how to achieve using MongoDB and PostgreSql for the same node app. I am seeing where it’s possible but no information on how to implement. Are you aware of any source of information on this?


#12

What’s the use case where you need both? i.e. if you’re using Postgres why not just use that, what is the situation where you feel you need Mongo as well?

It’s just a case of installing the two databases and then calling each one when you need to call them, it’s just twice as complicated with two interfaces to manage, when you could just have one. And Postgres can do everything Mongo can do, so seems overkill unless you have a quite specific usecase


#13

Why not assign each school an ID and link entries to said school. Conflicts resolved.


#14

two schools, two databases, but need to query/view both in reports, etc for district management. Is this the architecture you need?

There are two methods of view for the district model that can be used:

  1. query individual databases for data, then assemble the results for viewing on the screen, or

  2. query a central database that the two other schools update.

method 1 works for small environments, but the problem is the performance hit from connecting retrieving, storing that temporarily in memory, closing that connection and go to the next school for querying, ect. takes up a lot of resources and processing time. Granted, two schools are not a real big deal with this model, but I wouldn’t recommend it for like something of the size of 10 schools.

method 2 is more preferred, because each school has its own engine, then either at the time of db update (like inserting a new entry) updates both the school’s db and the corresponding school’s table(s) in the district db. another way of updating the remote is to store the table update commands in a db, then recall them using a server scheduling service like chron, then the server executes these updates to the districts server in the background. I have deployed something like this for a school system of a tribal government, including other db’s used for financial literacy learning. each school has an internal and a external read-only db (for students), the district has one (district=>schools), and the tribal government has one (dept of edu=>district=>schools).

I know you not trying to write something this size, but I wanted to share my db architecture with you since you are improving an education system with technology.

I did my project in php/MySQL
The public site of this project I explained is at: www.bcsibank.com just to give you some ideas…
I eventually want to find others to package this along with someone who wants to write financial literacy educational materials so that it can be deployed everywhere.


#15

Thanks Dan.
It’s a ticketing website that has a lot of social integration. The concern is bottlenecking on Postgre.
Our presently system serves multiple sales channels via http requests from other servers.

The main concern here is the scalability of Postgresql.
We are upgrading servers owing to expansion so database architecture is critical as we expand.

The idea is to handle the sales transactions with Postgresql and most other non-mission critical read requests with MongoDB.
This way the Postgresql DB does not have to do much work unless there is an actual purchase
MongoDB will handle most HTTP Requests and we can scale this easily as we grow

If I find a solution that I am comfortable with that allows failover, redundancy and scalability with Postgresql, I’d gladly go with this option.


#16

Thats fair enough, good usecase, but then just put both DBs in, I’m not sure what the main issue is? Just install both DBs. The app is just an interface for them, so hit the relevant DB with relevant requests; the bit you want backed with Mongo, just back with Mongo. The app code shouldn’t care what it hits, interface can be the same. First post made it seem like you weren’t sure what you were doing but you must have a pretty clear idea of architecture here; if you’re thinking about scaling in the way you describe then you already must have something pretty massive to start with?

Also look at Redis/MySQL setups, there should be more of those floating around & easier to find (I think) than Mongo/PG, will take some digging through github though. Not same use case as that will be caching, but should give ideas re setup


#17

Dan, thanks alot for the insight.
Yes we are starting from a relatively good place in terms of size. This architecture upgrade is pretty important for us.

I checked out Redis/Mysql and it started to look interesting, but then I noticed Mysql Clusters.
It seems that mysql clusters is exactly what I need as it offers horizontal scalability, failover and some degree of caching for improved response.