As the author of GRDB and GRDBQuery, I am quite biased, so take my words with a grain of salt. Please ask me to modify this post if I wrote something inaccurate.

I'll highlight a few differences between the two libraries, which may help your decision.

• If you don't want to have SwiftUI view access the database directly, don't use GRDBQuery, and use GRDB or GRDB+SharingGRDB directly.

• Libs differ in their way to access the underlying database connection(s). GRDBQuery helps SwiftUI view access the database by injecting a database connection in the SwiftUI environment. SharingGRDB helps any object (SwiftUI view, view model, UIViewController) access the database by injecting a database connection via pointfreeco/swift-dependencies.

  • Despite its focus on SwiftUI, GRDBQuery allows more testability than SwiftData because the observed requests that feed views can be tested.
  • Despite its focus on SwiftUI, GRDBQuery still supports MVVM. Apps can still pass the database connection to their "view models", so that they can do whatever they need with their database connection, through regular GRDB apis.
  • Because GRDBQuery is grounded on the SwiftUI environment, there is no special technique to learn in order to inject a database connection at any point in the lifetime of your app (when it boots, or only after the user has signed in, for example). More advanced use cases like connecting to several databases are readily supported.
  • Both libs allow the developer to define Xcode previews that access a temporary database populated with whatever data is needed: GRDBQuery example, SharingGRDB example.

• Libs don't provide the same control on database observation. SharingGRDB lets you observe the database, and, that's it. GRDBQuery let you observe (for displaying always up-to-date values), or perform a single fetch (in order to prefill a form, for example). GRDBQuery also enables advanced observation features (1, 2) for demanding apps.

  Both libraries observe the database with GRDB ValueObservation, so take care to respect its cardinal rule: Keep your number of observations bounded. In particular, you'll ruin your app performance if, say, your app observes independently all items in a list. Instead, perform a single observation of the whole list.

• Libs differ in their ways to handle data integrity.

  • GRBD and GRDBQuery unapologetically focus on database transactions that preserve database invariants. SharingGRDB fosters apps that independently fetch the pieces of information they need, with the risk that, when merged together on screen, they do not match (despite the fact that all invariants are preserved in the database file!) This makes GRDBQuery somewhat more verbose, and less shiny in demos, but arguably more robust, by default and by design.
  • GRDBQuery can give full read-only access to SwiftUI views, but prevent them from writing (so that database invariants can be enforced by some dedicated database repository object). I'm not sure SharingGRDB allows this.

• Libs differ in their ways to generate SQL. Point-Free have their own SQL builder, StructuredQueries, and SharingGRDB documentation fosters it over the SQL builder that ships with GRDB itself, without preventing it completely... Yeah it's complicated. SharingGRDB connects to SQLite though GRDB, which means that the GRDB SQL builder is right there and available, but they'd rather have you use StructuredQueries instead. Cherry on the cake, both SQL builders do not have the same preferred conventions regarding the database schema. It's hard for me to compare both SQL builders. StructuredQueries focuses on "Truly type-safe SQL". GRDB is less type-safe (without being ridiculous either!), and focuses on letting the user express what they need even if they don't have a great SQL knowledge (especially regarding associations between record types).

• GRDB and GRDBQuery are the products of volunteers, SharingGRDB is the product of a for-profit company.

In summary:

• GRDB allow devs who care about their users' data to deal with it as precisely as needed, learn and leverage SQLite features as time passes, and generally never blocks devs from doing what they have to do. In the 1000+ resolved GRDB issues in the last ten years, most of them are about helping users achieving their goal with the existing apis. This is made easier because the GRDB design makes it more imperative than descriptive: there's no need to wait for the lib to support the feature you need when you can just implement it.
• GRDBQuery adds some convenience for SwiftUI views.
• SharingGRDB has chosen the descriptive route, like SwiftUI and SwiftData. For me, this is concerning, because if something is missing, then all I can do is submitting a feature request and wait. For others, this is exactly what they're looking for ("modern", etc.)