HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
groue
GRDB.swift
Swift2015–2025
groue / GRDB.swift

GRDB.swift

A toolkit for SQLite databases, with a focus on application development

Data & Databases
Explore on GitHubRead Hacker News discussions
9Distinct people
21Mentions
0Explicit recommenders
8.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A toolkit for SQLite databases, with a focus on application development

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year21 dated mentions

Observed mentions: 2015-09-05 21:06:27 UTC to 2025-09-17 15:40:42 UTC.

0123452015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 2 submissions, 3 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC110
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC523
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC422
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC312

What Hacker News says

21 sources
wahnfrieden·Sep 17, 2025
The purpose is not iOS 13 (they perhaps should not place that in the lede). But even iOS 17 is hard to use swiftdata on, given indexes were not even added until 18. And many deploy still to iOS 17 or even 16. I don’t know why you see support for that as a suspicious negative. But for me the draw is: - Can use this outside SwiftUI views, unlike SwiftData - Can adopt future improvements without waiting on annual release cycle + several more years until I can sunset older OS compatibility - Performance: SwiftData has severe performance issues that are manageable with SQLite - Cross-platform: SQLiteData depends on GRDB which is perhaps close to merging support for Android (and already supports Linux), at least as an experimental trait: https://github.com/groue/GRDB.swift/pull/1708 By using it with https://skip.tools I can deploy the same Swif
Read the rest
tUI codebase to both iOS and Android. And with SwiftCrossUI I can target Windows, Linux too while reusing the same model/persistence layer code. Perhaps this will work in WASM too. And lastly, many apps already choose to use SQLite. You can see several commenters here who use GRDB in their projects. This library adds CloudKit sync to that which has previously not existed outside of broken experiments or proprietary in-house solutions. The CloudKit capability is more relevant than a decision for whether to use declarative syntax. Now that RealmSwift is dead, there are to my knowledge zero other alternatives to this new library and SwiftData/CoreData for a CloudKit-synced DB. Re: pointfreeco I’m unfamiliar with their other work and have no interest in TCA. This library has no dependency on TCA and no lock in on the esoteric or paid parts of their ecosystem that I can see. Most of what it does is provided by GRDB, which has some level of community support and production adoption even from within Apple’s own frameworks (Apple ships GRDB inside of iOS & macOS!). Your comments there seem like fear-mongering and irrelevant to this project. I suggest evaluating this independent of any perceived baggage from their brand’s other work.
In SQLiteData: A fast, lightweight replacement for SwiftData using SQL and CloudKit
groue·Apr 3, 2022
It is always safe, and by "safe" I mean "safe for data". You won't have to deal with data corruption. Precisely, see "How To Corrupt An SQLite Database File": https://www.sqlite.org/howtocorrupt.html Now concurrent accesses from different processes/connections can lead to runtime errors (SQLITE_BUSY), because the database happens to be locked by one connection. Those errors are greatly reduced by the WAL mode (https://sqlite.org/wal.html) which provides ultra-robust single-writer/multiple-readers semantics: - Writes can not happen concurrently (SQLITE_BUSY). - One can reduce the occurrences of such SQLITE_BUSY errors by using a built-in timeout (https://www.sqlite.org/c3ref/busy_timeout.html). - Several reads can happen concurrently, including with writers. - A writer connection can enter the "Serializable" isolation level. - A reader con
Read the rest
nection can enter the "Snapshot Isolation" level. For more details, see https://www.sqlite.org/isolation.html During all the years I've been developing the GRDB library (https://github.com/groue/GRDB.swift), I could never see SQLite fail its documented guarantees. This made it possible to build one of the most concurrency-focused SQLite toolkit for Swift, and I'm pretty happy with it (https://github.com/groue/GRDB.swift/blob/master/Documentatio...).
In SQLite B-Tree Module
chrisballinger·Apr 4, 2021
Very interesting concept, but I'd recommend people check out GRDB[1] if you're in search of a mature persistence layer for your iOS apps. It's a modern SQLite wrapper with a lot of conveniences for application development like value types, Codable mapping, Combine observables, etc. I've deployed it in production on a few apps so far, and it has been a real joy to use. 1. https://github.com/groue/GRDB.swift
In Dflat: SQLite FlatBuffers
groue·Aug 28, 2018
We start to see ORMs like Diesel (https://diesel.rs) or GRDB (http://github.com/groue/GRDB.swift) that radically simplify their domain by removing traditional ORM features like implicit uniquing, lazy-loading, or auto-updates. This of course gives more work to do on the client side. But this work is positive and often simpler than expected. With traditional ORMs, there is still some work to do, which often looks like fights: against misunderstandings, against leaky abstractions, against configuration levels that don't match the needs of application, and generally speaking against the framework. ORMs are not done yet :-)
In Solve Less General Problems
groue·Aug 2, 2017
I'd also like to thank the other for his attempt at raising the general awareness of transaction isolation. Even when you deal with simpler databases like SQLite, isolation is a serious topic. When serializing accesses hinders performances, dealing with the "WAL mode" that grants SQLite with single-writer-multipler-readers abilities is everything but trivial, because of the huge amount of documentation that has to be read in order to reach the desired level of isolation. I've written an SQLite library in Swift that provides by default the snapshot isolation level which grants most developers with both peace of mind, and non-blocking reads. Check out its "concurrency guide" if you're interested: https://github.com/groue/GRDB.swift/blob/master/README.md#co...
In Practical Guide to SQL Transaction Isolation

Showing the 15 most recent of 21 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.