Hacker News Reader

Comment by mikeocool | Hacker News Reader

GRDB/GRDB-Query (https://github.com/groue/GRDB.swift) is another solid library worth looking at if you're looking for libraries in this space, though it doesn't have CloudKit support out of the box.

The more SwiftData alternatives the better -- as it has a lot of rough edges, and Apple hasn't invested much in it since it's initial launch.

View on HN

Thank you (GRDB author here).

It is not mentioned in the README of the repository, but SQLiteData wraps GRDB to access the database and get notified of database changes (the meat and butter).

GRDB is by itself a solid "toolkit for SQLite databases, with a focus on application development", with both high levels APIs for everyday coding, and expert SQLite features for the demanding developers. Many apps rely on GRDB alone.

Oh hi -- Thanks for your work! Just finished replacing SwiftData in an app with GRDB and it was a pleasure to use.

After struggling with some issues in SwiftData, GRDB really hits the nail on the head in terms of providing a solid dev experience for the common cases, but allowing you to drop into the more advanced features when you need them.

You're welcome :)

Used GRDB many times in a previous life, thank you very much for your work

Sorry about that, just opened a PR to update the readme and docs landing page! Previously it was very clear that GRDB was being used under the hood, but now we will say it explicitly.

Thank you for GRDB! I am using it in a project now and it’s been great. About the benchmarks in this repo though, how can SQLiteData be faster if it uses GRDB under the hood? Are they doing something inefficient or are they bypassing GRDB in some way?

GRDB appears to encourage Codable which is very slow. It does not require it though and there are some alternatives, some of which are also slow. ("Slow" can still mean "fast enough", depending on the user.)

SQLiteData uses this library which uses Swift macros to generate performant interfaces to schema statically at build time: https://github.com/pointfreeco/swift-structured-queries

The alternative I've seen for doing this with GRDB seemed more cumbersome and lacks community adoption: https://github.com/Jasperav/GRDB-ORM You must define schema and queries in an unusual external file that a Rust tool transforms for you.

There is also this library which does not use GRDB but takes a similar approach to SQLiteData though you have to run a program that generates the bindings outside of your normal build: https://lighter-swift.github.io/documentation/lighter/perfor...

Now I understand. Thanks!

Yes. GRDB encourages Codable because the user can profit from the code generated by the compiler, and this implies that database values are accessed by column name, on top of the Codable runtime, and those layers have a high cost. When necessary it is possible to access database values by position, and in this case GRDB achieves speed of light (performance nearly identical as raw SQLite).

From my understanding this is a sample of the database values by position approach: https://github.com/Lighter-swift/PerformanceTestSuite/blob/m...

That approach benchmarks at 2.2x the duration of StructuredQueries (45% as fast): https://github.com/Lighter-swift/PerformanceTestSuite/blob/8...

18.819s vs 8.511s

So it appears that there is lightning-fast and lighting-faster.

Of course aside from comparing the dev ergonomics (138 vs 33 lines for the respective benchmarks), either may be fast enough depending on the use case.

BTW I did also see some discussion in swift-evolution about a future replacement for Codable but haven't tracked its progress. I hope they do because Codable is very convenient but tragically slow.

Yes, GRDB even w/ manual help is obviously not as fast raw SQLite. As much respect I have for the author "performance nearly identical as raw SQLite" is incorrect. Lighter also achieves some of the performance characteristics by avoiding allocations for bound parameters (such being statically generated). I didn't look into SharingGRDB yet, but it seems like those macros could accomplish similar performance, the other way around (Lighter works on the SQLite DB schema). What I'm not entirely sure of yet is why it even sits on top of GRDB in the first place, instead of just doing the SQLite parts itself. Marketing I suppose.

> Marketing I suppose.

Nope. And not sure where you get that idea. This release even involved a rename away from including "GRDB."

When 0.1 of the library was released, it was a simple adapter between our Sharing library and GRDB, thus the name SharingGRDB. As our needs grew, the tool evolved significantly, and both the Sharing component and GRDB have become more of an implementation detail. In the future we will consider supporting any SQLite adapter, even your libraries ;)

GRDB is an invaluable tool to me and, IMO, to the Swift community — thank you for open-sourcing your countless hours of work and expertise!!

> though it doesn't have CloudKit support out of the box

There is no CloudKit support for GRDB available anywhere except for via this SQLiteData package

"Harmony" was an experiment in adding it to GRDB on iOS 17+ but reports claim that it's broken. SQLiteChangesetSync is another earlier experiment that is unmaintained

I don't think it is an experiment, AFAIK it is used in a widely used application by the author.

Reply on news.ycombinator.com