I’d like to suggest considering a Distributed SQL database for this project. If you’re not familiar with this database category, it includes databases that are built natively as distributed systems. As “distributed-native” systems, they have that in common with NoSQL databases like Cassandra and MongoDB, mentioned in earlier comments here. But this category of databases also supports “SQL”, as the name indicates. Specifically, “SQL” refers to relational algebra and support for ANSI-standard SQL. In the past, we as an industry moved to NoSQL systems with the idea that relational databases could not scale cost-effectively, or at all in some cases. For the RDBMS technology at that time (~2007) that assertion was true. But now Distributed SQL databases have solved that problem and can effectively scale relational joins in a distributed system. Distributed SQL databases are easily adopted partly because they use existing common database protocols, viz. MySQL and PostgreSQL, so they work with existing drivers in any programming language, like Java, and with ORMs like Hibernate, mostly out of the box. Distributed SQL databases are also multi-model these days. That means that they support documents and JSON as first-class citizens just as well as traditional relational tables and rows. Because of these capabilities, Distributed SQL are replacing the last era of NoSQL databases like MongoDB and Cassandra as well as RDBMSs like Oracle, SQL Server and IBM DB2. Some examples of Distributed SQL databases are SingleStoreDB, CockroachDB and YugabyteDB. (Disclosure: I work for SingleStore.)
3 Likes
Thank you Domenic from your thoughts. Do you have any experience, insights or results (that you can share) about implementing openEHR on SingleStoreDB ?