The advent of the family of *edEntityClass functions in V12 looks very promising. Dataset and its related queries are ideal for initial exploration and rapid prototyping but with this new functionality, transiting to the Entityframework seems more apt when eying off scalable, relational-database-type implementations. It is straightforward to perform this conversion simply, say by assigning integer-named Entities to essentially act as primary keys to a Dataset's rows ... e.g.
convertToEntityStore[type_, dataset_Dataset] :=
With[{entities = Module[{x = 1},
Association @@ Query[All, (ToString[x++] -> #) &]@dataset //
Normal]},
EntityStore[type -> <|"Entities" -> entities|>]];
store = convertToEntityStore["titanicByEntities", ExampleData[{"Dataset", "Titanic"}]]
... but are there other things to consider as part of good, scalable practice? For example, should further typing take place and/or other properties/classes added? Is cloud-based delivery using EntityStore the way to go or does there come a point where it makes more sense to convert further into traditional databases and if so, at what point does this occur?

CanonicalNamewhich here would appear to be most naturally the passenger's name. Short of knowing these names however, stringed integers seem an apt default. In the "office rdb" documented example, the tables have a melange ofCanonicalNamesas perrdb = RelationalDatabase[ FindFile["ExampleData/ecommerce-database.sqlite"]]; EntityRegister[EntityStore[rdb]];(EntityList[#] // Shallow) & /@ rdb["Tables"]including a few that involve sequential/non-sequential integers ... – Ronald Monson Jul 01 '19 at 01:52