Kit Ruparel

I would really avoid building all of the scaffolding you need for the global server-server replication, eventual consistency and offline tools.

As long as your application architecture can fits a Key/Value pair type store, and you want master-master replication, then I'd start with AWS DynamoDB configured in Global Tables mode: https://aws.amazon.com/dynamodb/global-tables/

Then for offline-first access from client devices, use AWS Amplify, where (when used right) it's datastore feature will do most of the online/offline sync for you and let the developers focus on the mobile or web app. https://aws.amazon.com/amplify/features/#DataStore

I've had great success in using Amplify over very spotty connections (moving vehicles), using React and React Native for Web and Mobile applications respectively.

If your back-end data architecture really must be more RDBMS/SQL like, then consider whether you can use a central database in one geography, with all updates finding their way back there, then with read-replicas in other geographies. A good article on this, and suitable cloud-first databases to use, is here: https://read.acloud.guru/why-and-how-do-we-build-a-multi-region-active-active-architecture-6d81acb7d208

The most important question is where are you planning to host? On-premise, or in the cloud.

Particularly if you are planning to host in either AWS or Azure, then your first point of call should be the PaaS (Platform as a Service) databases supplied by these vendors, as you will find yourself requiring a lot less effort to support them, much easier Disaster Recovery options, and also, depending on how PAYG the database is that you use, potentially also much cheaper costs than having a dedicated database server.

Your question regards 'Relational or not' is obviously key, and you need to consider both your required data structure, as well as the ACID requirements of your application model, as well as the non-functional requirements in terms of scalability, resilience, whether you want security authorisation at the highest application tier, or right down to 'row' level in the database, etc. - however please don't fall into the trap of considering 'NoSQL' as being single category. MongoDB, with its document-store type solution is a very different model to key-value-pair stores (like AWS DynamoDB), or column stores (like AWS RedShift) or for more complex data relationships, Entity Graph Stores (like AWS Neptune), to stores designed for tokenisation and text search (ElasticSearch) etc.

Also critical in all this is how many items you believe you need to index by. RDBMS/SQL stores are great for having as many indexes as you want, other than the slow-down in write speed, whereas databases like Amazon DynamoDB provide blisteringly fast read/write performance, but are very limited on key indexing capabilities.

It feels like you have most experience with SQL/RDBMS technologies, so for the simplest learning curve, and if your application fits it, then I'd personally start by looking at AWS Aurora https://aws.amazon.com/rds/aurora/ .

I would really avoid building all of the scaffolding you need for the global server-server replication, eventual consistency and offline tools.

As long as your application architecture can fits a Key/Value pair type store, and you want active-active replication, then I'd start with AWS DynamoDB configured in Global Tables mode: https://aws.amazon.com/dynamodb/global-tables/

Then for offline-first access from client devices, use AWS Amplify, where (when used right) its datastore feature will do most of the online/offline sync for you and let the developers focus on the mobile or web app. https://aws.amazon.com/amplify/features/#DataStore

I've had great success in using Amplify over very spotty connections (moving vehicles), using React and React Native for Web and Mobile applications respectively.

If your back-end data architecture really must be more RDBMS/SQL like, then consider whether you can use a central database in one geography, with all updates finding their way back there, then with read-replicas in other geographies. A good article on this, and suitable cloud-first databases to use, is here: https://read.acloud.guru/why-and-how-do-we-build-a-multi-region-active-active-architecture-6d81acb7d208