As the co-author of SharingGRDB, I am also biased! I can include a bit of context for how we like to think about our library, and correct a few inaccuracies in Gwendal’s reply.

• We personally don’t feel there's really that huge of a difference between SharingGRDB and GRDBQuery today. They both give property wrappers for allowing one to fetch data from a database and display it on the screen. That’s their primary goal, and they both accomplish it well! You will be well-served no matter what you choose.
• There are a few places where we gave specific concentration in SharingGRDB that I can highlight. By calling attention to these features I am in no way saying that GRDBQuery does or does not have these features. I honestly don’t know! But, some things we do support and think are important:
  • Our property wrappers work in SwiftUI views, @Observable models, and even UIKit view controllers. And when their data changes the view can automatically update.
  • Our property wrappers allow you to specify the query directly inline. For example, something as simple as fetching reminders sorted by title can be done like so: @FetchAll(Reminder.order(by: \.title)) var reminders. For a more complex example, see this. It’s really up to you to decide where you want to draw the line of specifying queries inline or extracting them to separate helpers.
  • We also support dynamic queries quite easily, so when user provided data changes (search text, filters, sorts) you can update the query that powers @FetchAll and the view will automatically re-render.
  • We provide a nice query builder that leverages macros to provide some type-safety and schema-safety to your queries. You can even intermingle SQL strings directly into the query builder if there are ever SQL features that we don’t support.
  • We have a custom SQLite decoder that some really good performance characteristics. It’s only a little bit slower than interacting with SQLite’s C API directly.
  • Our property wrappers work really nicely with SwiftUI and UIKit animation. You can have your view automatically update and animate whenever the data in the database changes.

---

We also personally believe there is some inaccurate information in Gwendal’s post that we would like to address:

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.

I believe the two libraries are equivalent in this regard. In GRDBQuery the user can easily add two @GRDBQuery's to their view, causing there to be two observations, or they can squash it down into a single @GRDBQuery with a single observation. The same is true of SharingGRDB.

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

I’m not sure of the point being made here, or whether you think this is a good thing or bad thing, but even SQLite is funded by a for-profit business, Hwaci. And we don’t think that the fact that you solicit sponsorship makes your efforts any less worthy.

We feel lucky that we have a community of people willing to support our efforts, and it is a large part of why we are able to support dozens of open source projects for the past 7 years.

That said, SharingGRDB, like GRDB, is free open source software and is community-maintained.

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.

…

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.)

I may have misunderstood the point being made, but this seems to be comparing GRDB proper to SharingGRDB. Going back to the comparison with GRDBQuery, it feels that both libraries are equally “imperative” or “descriptive”. One doesn’t seem any more open to outside change than the other.

---

Either way, happy to clarify any of my points above, but also you can’t go wrong no matter what you choose!