Interesting question! My friends and I were just discussing databases this week… see here to get a great quick overview of your options:
I’d recommend FaunaDB. It’s serverless, and behind the scenes takes advantage of the best features from Graph, Relational, and Document databases. Plus, you define everything with GraphQL.
GraphQL is extremely powerful. Let’s say you want a list of the posts published in America. You would normally execute a query that returns all of the posts, so let’s say this returns 40,000 results. However, you only cared about the posts published in America, so you need your app to filter through those 40,000 results (megabytes of data), then show only the 5,000 from America. With GraphQL instead, you can say in your query, just give me back the results for the posts published in America, and it will return only those. Although, I haven’t used GraphQL myself with an iOS app yet. Bottom line is that the data still returns as JSON, but you can create more powerful and accurate queries.
My friend said your use case might be related to a streaming database (also feature of FaunaDB), but we don’t know about it enough to say more. I shot an email with your use case to this same group of friends, so will update as I get more (one was an Oracle database administrator for years. Oracle is the Ferrari of databases, super-pricey and often packed with features you don’t need).
You’d likely want to use a relational/ schema based database over NoSQL. The schemas fit easily to classes/ models in Swift. You define the schema, then you know that that data/ fields have to exist in your model. From there, you can directly map it to a struct in Swift.
In contrast, I’ve heard bad things about NoSQL. At first, it’s great, but later problems pop up. It’s like the Wild West: anyone can create any type of JSON document. That means sometimes the data you want exists there, while sometimes it doesn’t, because there’s no schema to enforce the rule that it must be there. So over time teams’ codebases grow larger and larger as they have to check if the data exists in a particular field. Versus with traditional SQL, you know the data must exist in that column. See CockroachDB for a serverless SQL database. Interesting post about migrating from NoSQL’s MongoDB to SQL’s PostgreSQL here: Why We Moved From NoSQL MongoDB to PostgreSQL - DZone
Also, I wouldn’t consider SQLite as one of your database choices. This database is good for development/ testing purposes, but not for production. At least that’s how we view it in the Python world.
Cheers,
Andrew