[dgllghr]

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?

[wahnfrieden]

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

[groue]

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

[dgllghr]

Now I understand. Thanks!