Sqlitedata: a Fast, Lightweight Replacement for Swiftdata Using SQL and Cloudkit
Posted4 months agoActive4 months ago
github.comTechstory
calmmixed
Debate
60/100
SqliteSwiftdataIos DevelopmentData Persistence
Key topics
Sqlite
Swiftdata
Ios Development
Data Persistence
The SQLiteData library is introduced as a fast and lightweight replacement for SwiftData, sparking discussion on the trade-offs between using an ORM and raw SQL, as well as the need for alternatives to SwiftData.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
2h
Peak period
16
2-4h
Avg / period
5
Comment distribution45 data points
Loading chart...
Based on 45 loaded comments
Key moments
- 01Story posted
Sep 17, 2025 at 9:27 AM EDT
4 months ago
Step 01 - 02First comment
Sep 17, 2025 at 11:05 AM EDT
2h after posting
Step 02 - 03Peak activity
16 comments in 2-4h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 18, 2025 at 5:46 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45275582Type: storyLast synced: 11/20/2025, 8:42:02 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
It employs a „last edit wins“ strategy for conflict resolution, which is fine in my case. Obviously could be too basic for collaborative apps.
In general though, I'm not sure who finds PointFree's work a net positive investment of resources, but the company seems to be in the business of reinventing the wheel and locking you in so that you'll pay for support. Meanwhile, Apple's own SDKs are free. And with Apple's history of source-breaking changes over major platform updates, plus given how even huge libraries/tools like Alamofire, Realm, RxSwift, Cocoapods eventually succumbed to oblivion, I can't think of why an Apple developer with any modicum of discernment would choose PointFree's tools over Apple's own--unless they are themselves caught by the allure of reinventing the wheel.
> And with Apple's history of source-breaking changes over major platform updates, plus given how even huge libraries/tools like Alamofire, Realm, RxSwift, Cocoapods eventually succumbed to oblivion, I can't think of why an Apple developer with any modicum of discernment would choose PointFree's tools over Apple's own--unless they are themselves caught by the allure of reinventing the wheel.
Isn't this just a blackpilled take in general? You're complaining that Apple software breaks, that other third party software is discontinued, and this somehow leads to the conclusion to avoid this library?
If you used a third-party lib written in Swift 1 and you had to move to Swift 2 because the next version of iOS requires the latter. Then you’ll have to wait for the lib developer to publish a version of their third-party lib for Swift 2 before you can publish your app. That’s the same kind of risk that you’re exposed to with source-breaking changes.
Admittedly, source-breaking changes have gotten less frequent in Apple’s major tooling updates, but the right mindset when developing for walled gardens like Apple is that it will happen again.
The fact that our library deploys back to iOS 13 is just our way of showing we care deeply about back deploying these tools so that anyone can use them. Certainly no one is deploying iOS 13 apps these days, but people definitely are deploying iOS 16 apps (and may be for another year or two), which has no access to SwiftData.
And investing time into learning a third party library is just the name of the game when one feels that the tools Apple provides do not suit their needs. Luckily our library mimics many of the patterns that one is used to with SwiftUI and SwiftData, but has the benefits of being based on SQLite, is open source, and not a proprietary technology.
And I'm not sure what wheel we are reinventing here. We feel most of our libraries are specifically filling holes that Apple has left open. We also don't do a ton of paid support with companies, but we certainly do answer dozens of questions on Slack, Twitter, GitHub discussion, etc, every day. All for free.
> learning a third party library is just the name of the game when one feels that the tools Apple provides do not suit their needs
Or you can just wait a couple more platform updates instead of always being on the bleeding edge. Apple’s frameworks might not be perfect, but they’re quite exhaustive, and libraries that aim to fill in those gaps are offering diminishing marginal returns that would be unnecessary in 1-2 WWDCs.
I’m sure there are apps small enough to plan for short time horizons, but for companies who plan for their apps to run for half a decade or more, this is the sort of library that you’ll soon mark as tech debt and then refactor for removal when its approaches eventually make it to Apple’s own SDKs. The historical precedent is there.
> open source, and not a proprietary technology
Yea those are great virtues elsewhere but they stop becoming priorities the moment you pay for the license to develop for a walled garden and agree to its T&Cs
So your advice is to use CoreData until 2028 or so until we can terminate iOS 17 users and start using WWDC24 SwiftData.
And then maybe a few years from now (meaning usable by 2032) Apple fills SwiftData's gaps that SQLiteData meets today (ability to use it in background fetch tasks, scalable performance, usage outside of SwiftUI views, fast JSONB storage & querying, FTS) or has the capability to meet in the near future (sharing, public database etc.).
That's neither compelling nor industry standard, and is why so many businesses haven't adopted SwiftData and have moved on from CoreData.
It's the same reason PSPDFKit built up to a 9 figures business - no one wants to wait around for years and years for Apple to maybe incrementally improve PDFKit and also not provide any support, developer relations, or ability to fix a bug yourself.
Everything you just said is a dishonest excuse so that you can play with a new library using your company’s money and while letting them incur the additional risk of breakage or tech debt. Nothing is stopping you today from using Core Data to build an observable model or to partially adopt SwiftData just in the functionality that it can sufficiently cover.
Using TCA has been a great tool for me in my toolbox and it’s very clear how much time and effort goes into making these libraries, documentation, videos, online support, etc.
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 SwiftUI 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.
Many users value iCloud sync because it keeps their data private to their own Apple account, without having to share access to their data with the app developer's servers.
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.
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.
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.
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...
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.
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 ;)
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
You need to carefully weight the costs of abstractions you adopt. That goes double (or triple or quadruple) for data access, which is typically the central point of an app.
When sqlite is involved, I'm really doubting an ORM is worth it in the great majority of cases.
That's because sqlite is robust, mature, full-featured, very well documented, has demonstrated long-term viability, has a commitment to backwards compatibility and support, etc. I think it makes the most sense to implement an application-level data-access layer and have it use sqlite as directly as possible.
What sqlite doesn't do that an app needs is dealing with Swift types. I.e., the grunt work of the sqlite3_bind_* and sqlite3_column_* calls to transform Swift values to and from sqlite3 values. (And to a lesser extent, various Swift-isms for quality of life.) But you can have that without the rather more intrusive footprint -- and therefore much higher cost -- of an ORM.
The things you say that SQLite doesn't do is exactly what SQLiteData provides (Swift-friendly bindings for encoding and decoding data from SQLite), and more. There's a footprint, as there is with any library, but there is no ORM level of abstraction here.
One problem with data access wrappers is that what's both above it and below it have strong app concerns. The developer needs to understand and control what's below it, so an intermediate abstraction gets in the way. That is, in addition to understanding the lower-level, they also have to understand the intermediate abstraction, and how it maps to the lower level. So it's really best if the API surface is minimal.
What I would want is an API where the core is something like:
bindParameters(pStmt, anEncodableThing) readRowColumns(pStmt, ADecodableThing.Type) -> ADecodableThing
where pStmt would be as minimal a wrapper around a sqlite statement as is feasible (maybe even a pointer to a sqlite3_stmt directly?). There might be a minimal (non-existent?) wrapper around the sqlite3 connection too. (The sqlite pointer should be a public member of any wrapper, so you can call any sqlite3_ functions you want).
(I'd want some convenience methods too, that combine bindParameters and readRowColumns with preparing a statement and stepping through it, like sqlite's exec.)
Now, I know this doesn't address CloudKit sync at all, but I think a similarity minimal type-focused binding is best there too. It has nowhere near the 5-star API that sqlite has so there's a better argument for wrapping it, but sync tends to quickly accumulate app-level concerns when it comes to the exact details of sync conflicts, so you might as well keep that at app level. I think there maybe a set of composable convenience methods might do it, to handle the pain points without hiding the details you'll need access to.
Anyway, my point is NOT that sqlitedata is bad, it's that people should be really careful about taking on the costs that it has, and consider whether it will ultimately cause more problems than it solves. Meanwhile, sqlite is world-class -- you want to wrap it as little as possible.
(Previously I rolled my own sync with RealmSwift but that’s now dead.)
Without that, my only alternatives are SwiftData or CoreData, with severe downsides.
Re: ORM, the SwiftData-like ORM part of SQLiteData is actually completely optional. You can write SQL statements directly via #sql: https://swiftpackageindex.com/pointfreeco/swift-structured-q... You can wrap usage of this in your own method so that you can swap out SQLiteData in the future without lock-in.
Re: Swift types, you may roll your own mapping, but performance is not trivial. Here is a benchmark from SQLiteData:
Orders.fetchAll setup rampup duration
I found Enlighter and Lighter more intrusive to adopt, and the other open source solutions far slower (too slow for my needs, where my users have hundreds of thousands or millions of rows within the iOS apps)Our library does allow this a little bit, in addition to a Swift API for building queries. You can write SQL as a string while still using the schema information exposed from the @Table macro. For example, a query to select all reminders lists along with a count of the reminders in each list: