I'm sure this has been asked multiple times but for me it's more specific as I know what I'm building. I wrongly posted this to stack-overflow (now removed) so I'm hoping this is the best place to ask.

I'd like your help deciding how I should move forward database wise for the platform I'm building.

I'm currently using the MERN stack and targeting browser and mobile (with react native). The platform is essentially a conversation based ticketing system built around groups. Each group will have multiple users and documents associated with it. There seems to be a lot of relational stuff but a load of real-time messaging too.

I'll have multiple clients with potentially 50-100k groups each, then a load of tickets (real-time conversations) for each group. There may also different types of tickets with a slight variation in the data saved to the database.

So my question is, in my instance what's more suitable NoSQL or MySQL or a combination of the two somehow? It's also worth mentioning I intend to use AWS to host everything (So DynamoDB or RDS).

Cheers :)

closed as off-topic by gnat, Thomas Owens May 23 '18 at 13:33

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to find or recommend tools, libraries, programming languages, resources (including books, blogs, tutorials, and examples), or projects to undertake are off-topic here as they attract opinionated answers that won't have lasting value to others. You may be able to get help in The Whiteboard, our chat room." – Thomas Owens
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Doesn't matter at all based on what you've described. – Paul Oct 25 '17 at 22:14
  • 1
    Doesn't MERN stand for MongoDB/Express/React/Node.js so by expressing MERN haven't you already decided on a persistence choice? – Sign Oct 26 '17 at 14:42
  • We are currently using MongoDB for the prototypes but this is more for the production version, I want to make sure I start the real build with the right stack to avoid problems later on if possible. – Sam Tassell Oct 26 '17 at 15:04

We don't know what you're going to persist in the db (vs. deal with in memory), what write volume, what is in transactions, what read volume, what joins etc..

Further, we don't know about evolution of your application: A simple new requirement may blow a NoSQL database out of the water, while a SQL could easily accommodate.

To add to that, it sounds like you're in an rather early stage of development.

So, probably the best answer is SQL. SQL is feature rich and will lower development time, so will probably offer a time-to-market benefit and overall lower cost especially if your application requirements grow or change over time.

You'll be able to concentrate on correctness and following where your market leads you instead of writing extra code to deal with high performance but more limited databases.

If you go the other way you may suddenly find that some new and previously unforeseen requirement requires you to write a lot of code to make up for lack of joins, lack of transactions, or some other.

When you fully understand the data models, updates, and queries, and are fairly certain that the models are stable, you can optimize within SQL or switch to NoSQL, or use a multiple databases as in CQRS, which has a separated (typically denormalized) read model and (an update-oriented) write model.

  • There are a load of stakeholders that exist in each group, as well as documents and tickets/conversations. It is all relational so potentially a load of joins. My main concern is that SQL wont be speedy enough to handle the real-time messaging happening in said tickets, secondary to that the tickets may also contain custom workflows, which may have different schemas but still under a standard ticket (something I know NoSQL is good at). – Sam Tassell Oct 26 '17 at 8:03
  • Might something like RethinkDB be an option? Seems to be the best of both worlds but my concern is I want something ready for production thats managed. – Sam Tassell Oct 26 '17 at 8:07
  • 1
    @SamTassell "My main concern is that SQL wont be speedy enough" Based on which metrics? Did you actually measure anything? – Vincent Savard Oct 26 '17 at 13:24
  • 1
    Abstract the storage mechanism from the business logic of the real-time messaging so that if you find through use or perf testing that the RDBMS can't provide the performance you need, you can easily refactor to NoSQL. – Mike Partridge Oct 26 '17 at 14:44
  • Let not one component (messaging) of your application decide for every other components (ticketing, groups, etc). Like Erik says, once you realize what the system actually needs, make the required change. – Rishabh Oct 26 '17 at 17:22

The conversation ticketing system would be well suited for DynamoDB. Use a unique id for the prefix, specify a range query element based on group or simply a timestamp, and finally you can use TTL feature to remove old posts automatically over time if you want (additionally could be sent to Streams and S3 archiving even). Unlike standard SQL, DynamoDB can continually grow and you don't need to think about sharding.

Not the answer you're looking for? Browse other questions tagged or ask your own question.