Choosing between NoSQL and Relational databases while having both flexibility and consistency requirements
To answer your questions directly:

&quot;Since we'll have different sheet structures, is NoSQL a better option than a relational database?&quot;
A. Probably not, unless each of those sheet structures are very tightly related as one application that they'd all be stored in the same few tables. Otherwise it sounds like you just have a series of structured datasets (multiple applications) that can be represented each with their own different set of tables. This is quite normal and can easily be implemented in either a Relational Database Management System (RDBMS) or a NoSQL database, so no differentiation here.

&quot;The users will go on using spreadsheets and may change their sheet structure on the fly. Will this be a lot of trouble for NoSQL or relational databases such as SQLite?&quot;
A. Are the spreadsheets consumers of the data that was saved down to the database, i.e. besides writing to the database do the spreadsheets also need to read back from the database? If so, then changing structures is something you'll need to handle regardless of which type of database you use, the problem just occurs at different layers of the application. With a RDBMS you need a process to handle managing schema changes in the database that have occurred at the client, otherwise your database won't be storing any new data that is entered. With a NoSQL database, your problem exists in the other direction, when pulling data back into the client's new schema but the instance of data from NoSQL is still out of date and doesn't match the client. With Excel, it may actually be more forgiving though and just leave those columns blank. But keep in mind Consistency is also different in NoSQL should you choose to distribute the data across multiple nodes. It is eventually consistent, which means one user of a spreadsheet may receive a different version of the schema vs another user of that same spreadsheet, if the data from the newer structure hasn't been replicated to the other node yet. More of this on the answer to your next question.

&quot;NoSQL does not support the ACID of relational databases, does it mean that data may get corrupted when multiple users work on the same record? We normally would like consistency.&quot;
A. NoSQL follows the BASE principles (and is bound by the CAP theorem), which means unlike a RDBMS that follows the ACID principals, it is eventually consistent. This means a change to the database, including the change of the data itself, is not guaranteed to instantly be replicated across all nodes of which that database is distributed across. But it will be eventually replicated and consistent across all nodes. In regards to your question, that does not mean data is any more likely to be corrupted (from the system's perspective) if you use a NoSQL database vs a RDBMS and multiple users are changing the same record. Rather, it just means that the same record could be in multiple different states at the same time between different nodes, until the last in (generally) change becomes synchronized across all nodes of that database so that it becomes eventually consistent. A RDBMS generally employs an algorithm with a locking mechanism to ensure that consistency is immediate and that the same record is never in more than one state at a time.

&quot;If we maintain an optimized database but still want to be able to export selected portions or entire as CSV or JSON files? Will NoSQL or relational work better?&quot;
A. At a high level, I don't believe you'll find any differences here between either. It's an equally achievable goal for both types of database systems, and the differences will be very low level detail specific as you're getting into it. Some RDBMS natively support storing and/or exporting the data as JSON and CSV formats, and typically NoSQL databases already store (or retrieve) data as JSON and there should be ways to convert the results to CSV with modern implementations of those databases.

&quot;How to handle access control from scratch if we do it online? Will this affect the choice of database tech?&quot;
A. By &quot;doing it online&quot; do you mean a cloud-based solution? If so, this shouldn't change anything from a security standpoint. Either way, all modern database systems have a way to setup accounts either directly in the database system itself or mapped to another security system. For example, the Microsoft SQL Server database system offers the ability to either create dedicated Logins to the database or leverage Active Directory such that you can define access control within the database on top of Windows Users and Groups, and this still functions the same even when using Azure (Microsoft's cloud solution) to host your database. Similar ideas apply to other modern database systems too.

&quot;For this type of system, should we hire a database expert dev and/or maintainer? Can we build on some free/open-source infrastructure that requires the least amount of backend/frontend, security tech R&amp;D?&quot;
A. You sound like you have a lot of questions and thinking to do around the problems you're planning to solve, so if it's possible, hiring someone with strong database experience (especially one who has worked with both RDBMS and NoSQL) would be only of a benefit to you. Currently with the information you provided and based on the questions you've asked, I don't objectively see any distinguishing factor to choose one type of database system over another. My only subjective opinion would be to go with a RDBMS since it sounds like your data is structured at least (even if it does change - that's fine in a RDBMS) and if the eventual consistency of NoSQL can be an issue for your use-cases. If you're looking for an open source and free RDBMS then I'd recommend looking into PostgreSQL.