MSSQL

Of course both are capable of storing this data and technically possible to migrate to. For rich content that contains lots of different types of content nested together, the flexible structure of a NoSQL like MongoDB even has advantages. However, since you asked, I have to assume that you are less familiar with NoSQL systems and thus recommend the one that is more similar to MSSQL. PostgreSQL is another newer SQL database and would let you keep the old database's structure.

Hi Yeongju, What do you mean by private network? Are you talking about limiting the users allowed to use the app or where the data is stored? I'd be happy to help you! Connect with me on linkedin - https://www.linkedin.com/in/dominiquebhicks/ or book a call if you'd like help exploring - https://calendly.com/dominique-sales/discovery-call-with-stream Thanks!

Hi Yeongju. I work for Sendbird. Sendbird runs in the cloud. Since you mention private network and connecting with MSSQL, it sounds like you need an on-premise chat solution. CometChat claims to support on-premise. You might also look into open source chat solutions. https://medevel.com/12-open-source-chat-and-messaging-development-sdk-and-frameworks/ Hope this helps.

Flyway is a tool to apply incremental changes to an existing database. These changes can be data changes and/or data model changes. It won't help you with the migration from SQL Server to PostgreSQL or any other combination.

My recommended approach would be:

1. Migrate the current MS SQL database to PostgreSQL

1.1. dump current DB - best would be as SQL statements - the recommended tools can help you with analyzing the current database schema, use can rewrite it for the new schema, dump data, restore data, test queries, ...

1.2. make changes to the DDL statements (CREATE TABLE, CREATE SEQUENCE,...) if necessary - essentially make a port to PostgreSQL; adapt indexes, stored procedures, views, triggers,...

1.3. create a database instance on PostgreSQL and import adapted structure and data

1.4. automate the dump and restore part as complete as possible to avoid errors on the final migration

1. Update/adapt and test application with new PostgreSQL database. - essentially fork your application and start a new flyway/application history with the new PostgreSQL schema.

2. Repeat steps 1 and 2 until everything works as expected

3. Go Live: deploy everything in production (take application down, migrate database, change db connection info, apply new application with PostgreSQL)

4. from there on use flyway to do incremental updates in your database matching the changes in your entity/repository classes. initial Flyway migration (for example V10basescheme.sql) should be the schema made in step 1.2.

MySQL AB doesn't implement anything in MySQL until they can find a way to do it efficiently and, often, more efficiently than other systems. So although I don't have experience with benchmarking JSON_TABLEs or similar new features, their development philosophy alone suggests that version 8 for the latest features would be a safe jump without sacrificing system performance.

MySQL 8.0 is significantly better than MySQL 5.7. For all InnoDB row operations, you'll see a great performance improvement. Also, the time taken to process transactions is lower in MySQL 8.0. Moreover, there has been an improvement in managing read and read/write workloads.

Kafka is an Enterprise Messaging Framework whereas Redis is an Enterprise Cache Broker, in-memory database and high performance database.Both are having their own advantages, but they are different in usage and implementation. Now if you are creating microservices check the user consumption volumes, its generating logs, scalability, systems to be integrated and so on. I feel for your scenario initially you can go with KAFKA bu as the throughput, consumption and other factors are scaling then gradually you can add Redis accordingly.

I first recommend that you choose Angular over AngularJS if you are starting something new. AngularJs is no longer getting enhancements, but perhaps you meant Angular. Regarding microservices, I recommend considering microservices when you have different development teams for each service that may want to use different programming languages and backend data stores. If it is all the same team, same code language, and same data store I would not use microservices. I might use a message queue, in which case RabbitMQ is a good one. But you may also be able to simply write your own in which you write a record in a table in MSSQL and one of your services reads the record from the table and processes it. The most challenging part of doing it yourself is writing a service that does a good job of reading the queue without reading the same message multiple times or missing a message; and that is where RabbitMQ can help.

I honestly don't know if this could help but, I'll speak from my similar experience with Django. I had to do for a client a dynamic map in real time so that users can select their seats for a specific event. In the first MVP tickets sold in less then 10 minutes, over 400 users at the same time online trying to buy the seats. (I mention this to get in the context of why I used it).

We achieved this with Django, Socket.IO, PostgreSQL and for the frontend React. With the power of Socket IO we manage to achieve a real time connection with the database with a reaaally low response time.

The drawbacks of Django are that everyone knows that Django is not really good for real-time activities but in combination with Socket.IO this can be achieve really good.

I hope that in some way I helped. 👍🏼

I asked a friend who's a 10x Python engineer for some help getting you an answer here. He recommends:

I don't think there are any robust ORMs for asyncio. There's Gino but I haven't evaluated it. I would honestly use an asyncio SQL connector, manually write the request, and implement a mapping layer myself.

Asyncio is still a bit weird a lot of libraries hack compatibility layers onto it. It's probably better to use aiohttp alone instead of putting Tornado on top of it.

ORMs can be painful and newly created ones on new platforms are even more painful.

Hope that helps!