This. Querying JSON at full speed in SQLite with virtual columns and indexing. It’s what I do in my iOS podcast app ”Updates”. I love SQLite so much (and #grdb is a great Swift wrapper library).
https://www.dbpro.app/blog/sqlite-json-virtual-columns-indexing
#GRDB
@groue I opened a new discussion here:
https://github.com/groue/GRDB.swift/discussions/1821
Will describe the changes in a couple of parts to make it more manageable to write/read.
Apart from some minor tests that probably fail because of Linux specific things, actually most failures are in the DatabasePoolConcurrencyTests. Need to see whether this also occurs on macOS, and if not see what's causing this on Linux #swift #swiftlang #linux #grdb #sqlite
Fixed the build of GRDB on Linux and now trying to fix the failing tests. More than 400 tests are failing so it was difficult to see which tests were, but luckily I found:
🚀 I've just shipped #GRDB v7.6.1, that fixes a race condition introduced three days ago in v7.6.0: Please upgrade!
Version 7.6 makes it possible to access Task locals from async database accesses. This improves GRDB integration with toolings that rely of Task locals. For example, your tests can now use the #expect macro from within an async database access.
Happy birthday, #GRDB! The first recorded commit was on June 30, 2015 🎂
New blog post: Caveats Using Read-only SQLite Databases from the App Bundle
https://twocentstudios.com/2025/06/07/sql-databases-bundle/
A quick debugging story where I learned some new things about SQLite's journal mode while building an database export/import feature for Eki Live.
TLDR:
- Journal mode is embedded in the sqlite database file itself.
- The `backup` command changes the journal mode of the target database to match the source database.
- Check the journal mode of a database with `sqlite3 db.sqlite "PRAGMA journal_mode;"`.
- Change the journal mode of a database with `sqlite3 db.sqlite "PRAGMA journal_mode=DELETE;"`.
Just loving the SharingGRDB framework! The @pointfreeco guys really modernized swift persistence: https://github.com/pointfreeco/sharing-grdb
Getting a strange linker error with swift on Linux. I'm developing a cli app that uses another SPM package. That package uses GRDB and compiles. When trying to compile the cli app I get a linker error with sqlite3. In the screenshot below it looks like lsqlite3 has been included multiple times for linking? Anyone got an idea?
I have a nice #GRDB branch that simplifies the definition of SQLite requests from Swift code:
// 🙄 String-based (current state of the lib)
Player.filter(Column("score") > 1000)
// 😐 Enum-based (current state of the lib)
Player.filter(Player.Columns.score > 1000)
// 🤩 NEW
Player.filter { $0.score > 1000 }
It comes for free for record types that follow the recommended practices (i.e. define a nested `Columns` enum). 🎁
The commit that updates the demo app shows a nice win, at +9/-44 https://github.com/groue/GRDB.swift/commit/261c0ccf866029c0f65a88b881aabf46effc4f9e
The problem is that it breaks apps that define their records in packages/frameworks. The `Columns` enum must become `public` when the record type is, or the compiler won't compile it (even if its members are not public). 😖
In order to avoid the breaking change, I'll have to choose a name that is not `Columns`.
TableColumns? RecordColumns? Cols? Col? C?
In my own practice, this type sometimes contains expressions that are not columns, as below. Maybe the name should not refer to "columns", after all. TableLayout? TableComponents? SQLElements?
enum Columns {
// The date column
static let start = Column(CodingKeys.start)
// An expression derived from the date column
static let startDateUTC = SQL("date(\(Columns.start))").sqlExpression
}
One of the best things about #GRDB is the excellent documentation, which covers real life use cases and rationals, e.g. for #SwiftLang concurrency: https://swiftpackageindex.com/groue/grdb.swift/v7.0.0/documentation/grdb/swiftconcurrency
I've been building out the updated database and noticed queries weren't joining the lens information. The camera and film stock loaded and the queries didn't have any typos. Eventually I tracked down the issue to GRDB's pluralization support: “lens” looks plural so it was attempting to load values from a table called “len”. Luckily overriding the name was easy enough
@helge #GRDB kind does what I want, but yes, it's a little bit too heavy weight, for what I want. Then again, I guess I need to think a little bit more about how I rank my difference priorities (performance, lightweight, API, features, etc.)… Background: I am about to movie a larger codebase away from CoreData (since it seems to be a dead end, though it is still working). Therefore I want to figure out what's the best solution for, say, the next 5 years. Thanks for sharing your insights!
@h_r_w_go To maintain a core idea of Lighter (all access code statically generated, performance that is equal or better than usual handwritten #SQLite C API code) this would probably require #SwiftLang macros which are still in bad shape for 3rd parties (unacceptable compile times).
But I suppose #GRDB does what you want? Too much?
https://github.com/inlinehq/GRDB.swift
friendly fork of GRDB with SQLCipher included. (for various reasons, this isn't practical with SPM and GRDB.) this just caught my eye as a migration path for Feditext's GRDB+SQLCipher fork; hopefully it's backwards-compatible.
Reading pre-WWDC summaries and wish lists, I’m starting to think that going with #SwiftData for my toy podcast player wasn’t the best idea. Plain old #SQLite wrapped in #GRDB and Harmony or similar for CloudKit sync is beginning to look more and more appealing. SwiftData seems to have too many bugs, corner cases and gotchas. I’ll see what WWDC brings.
Did you know #GRDB can run on Windows? I just learned that today: https://github.com/groue/GRDB.swift/discussions/1498
#GRDB 7 will drop CocoaPods support.
Some folks will be able to migrate to SPM. But folks who use GRDB+#SQLCipher will be stuck with GRDB 6.
I'm not pleased with the situation, so please chime in the linked discussion below: your experience may help!
Client Info
Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst