Stream: implementers
Topic: Databases Suitable for FHIR Resources
ravi.kuchi (Nov 25 2016 at 21:29):
Not sure if this topic has been already discussed, wanted to know what databases are to be looked at when we are looking to save and retrieve FHIR resources. We are evaluating MongoDb, Postgress,...any suggestions and comments will be helpful... Two factors that are of major importance for us are 1) Integrity issues and Transaction concerns 2) Since the DSTU2 to DSTU3 structures and upcoming releases indicate considerable changes in the FHIR resources the database should be flexible to accomodate and should not pose a challenge while migrating..
nicola (RIO/SS) (Nov 25 2016 at 21:31):
Definitely postgresql :) Transnational, jsonb , advanced indexing, SQL, plv8, fast batch update operations (take a look at fhirbase)
Grahame Grieve (Nov 25 2016 at 21:58):
fundamental choise = relational vs post-relational. post-relational has many advantages, but chained search with transactional integrity turns out to be hard in that case
Grahame Grieve (Nov 25 2016 at 21:58):
but structure changes won't be solved by any different choice in database structures. You'll have the same problems whatever
nicola (RIO/SS) (Nov 25 2016 at 22:04):
@Grahame Grieve By post-relational do you mean document databases like mongo, couchdb, rethinkdb? They are usually called NoSQL :) Here is a notion of NewSQL databases https://en.wikipedia.org/wiki/NewSQL. PostgreSQL could simulate consistent document database until you have terabytes of data (i.e. CAP).
Grahame Grieve (Nov 25 2016 at 22:05):
yes i meant nosql, but I have also worked with - and still do - relational databases that have nosql because theys are pre-sql. so I find post-relational a better description of the idea. Postgres is trying to be jack-of-all-trades here, and you could use it either way
Grahame Grieve (Nov 25 2016 at 22:05):
but you stll have a choice
nicola (RIO/SS) (Nov 25 2016 at 22:08):
With document databases there are real problems with transnational integrity, most of them provide transactions only on document level. A lot of problems with joins and query language expensiveness, some of them usually build materialized views to handle it.
nicola (RIO/SS) (Nov 25 2016 at 22:10):
Better keep name "post-relational" for logical databases like datomic (datalog) :)
Vadim Peretokin (Nov 30 2016 at 22:09):
Just be aware of precision loss on decimals in whatever solution you're considering. FHIR is pretty strict about it (http://hl7.org/fhir/2016Jan/datatypes.html#precision) and understandably so
Stefan Lang (Nov 30 2016 at 22:27):
+1 for PostgreSQL. There are even benchmarks telling that it is faster than MongoDB when it comes to JSON handling. Plus: a relational database is more performant when it comes to aggregations. PostgreSQL can easily simulate anything you could do in MongoDB and outperform it most of the time while still being capable of doing all the relational stuff where you need it.
Last updated: Apr 12 2022 at 19:14 UTC
