SQLite a mobilfejlesztésben: mi ez és hogyan működik

Mi az SQLite?

Az SQLite egy C nyelvű könyvtár, ami relációs ADB-t valósít meg külön szerver nélkül. Közvetlenül az alkalmazásba ágyazódik be, és az eszköz fáj lrendszerében lévő szokásos fájlba olvas és ír adatokat. A könyvtár mérete körülbelül 600 KB, ami az SQLite-ot a legkönnyebb teljes értékű SQL-adatbázissá teszi.

Az SQLite támogatja az SQL:1999 szabvány nagy részét, beleértve a JOIN-t, részlekérdezéseket, triggereket, nézeteket, indexeket és ablakfüggvényeket. A korlátozások az ALTER TABLE-t (korlátozott támogatás) és a teljes RIGHT/FULL OUTER JOIN-t érintik. Ennek ellenére mobilalkalmazások számára az SQLite funkcionalitása a helyi tárolás eseteinek 99%-ában elegendő.

A Stack Overflow (2025) fejlesztői felmérése szerint az SQLite a legnépszerűbb adatbázis a beágyazott megoldások számára és a harmadik legnépszerűbb az összes ADB között a MySQL és a PostgreSQL után. A mobilfejlesztésben az SQLite minden alkalmazásban használatban van — közvetlenül vagy burkolókön keresztül.

Az SQLite főbb jellemzői

Zero-configuration — az SQLite nem igényel telepítést, jogosultságok beállítását, felhasználók létrehozását vagy szolgáltatás indítását. A könyvtár csatlakozik a projekthez, és az adatbázis egy függvény meghívásával jön létre. Ez győkeresen leegyszerűsíti a telepítést a kliens-szerver ADB-khez képest, ahol szerver telepítése, portok beállítása és felhasználók konfigurálása szükséges.

Az SQLite adatbázisfájl egy szokásos platformok közötti fájl, ami másolható, elemezhető, hálózaton keresztül küldhető vagy biztonsági másolatból visszaállítható. A fájlformátum API szinten stabil: a 2004-ben létrehozott SQLite 3 fájlok a könyvtár aktuális verziójával nyílnak meg, ami garantálja az adatok hosszú távú kompatibilitását.

Hogyan épül fel az SQLite: architektúra és tárolás

Az SQLite architektúrája nyolc virtuális gépből áll: Tokenizer, Parser, Code Generator, VM, B-Tree, Pager, OS Interface és Utilities. Az SQL-lekérdezés átmegy a Tokenizer-en (tokenekre bontás), a Parser-en (AST építése), a Code Generator-on (bájtkóddá alakítás), és a virtuális gépen hajtódik végre, ami a B-Tree-n és a Pageren keresztül olvassa az adatoldalakat.

Az SQLite B-Tree-t használ a táblák és indexek tárolására. Minden tábla külön B-Tree-ként van tárolva, ahol a levél csomópontok tartalmazzák az adatsorokat. Az indexek szintén B-Tree-ként vannak tárolva, de kulcsokkal a levelekben. A Pager kezeli az oldalak betöltését (alapértelmezetten 4096 bájt) a fájlból a memóriába, ACID-tranzakciókat biztosítva naplón vagy WAL-on keresztül.

Naplózási módok

WAL (Write-Ahead Logging) — az ajánlott mód mobilalkalmazások számára. A változtatások először egy külön WAL-fájlba íródnak, majd időszakon átkerülnek a fő adatbázisba. A WAL lehetővé teszi az egyidejű olvasást az adatbázisból (régi adatok) és írást abba (WAL-on keresztül), ami javítja a többszálú alkalmazások teljesítményét. A szabványos napló (rollback journal) blokkolja az olvasást írás közben.

A módok közötti váltás egyetlen SQL-lekérdezéssel történik: PRAGMA journal_mode=WAL. A háttérszinkronizációval és egyidejűleg adatokat olvasó UI-szállal rendelkező mobilalkalmazások számára a WAL jobb teljesítményt és interfészblokkolásmentességet biztosít.

SQLite összehasonlítva más adatbázisokkal a mobilfejlesztésben

Az SQLite nem az egyetlen lehetőség a helyi adattárolásra, de a legáltalánosabb. A Realm nagyobb sebességet kínál a memóriában lévő objektumok közvetlen eléréséhez, de saját NoSQL-formátumot használ és nagyobb könyvtármérettel rendelkezik. A Core Data iOS-en egy ORM-réteg az SQLite felett, ami objektumgráf-kezelést és műveletek visszavonását ad hozzá.

A legtöbb alkalmazás számára az SQLite marad az optimális választás a kiszámítható teljesítmény, a gyártófüggetlenség és az idő próbáját kiálló stabilitás miatt. A Realm és a Core Data összetett objektumgráfokkal, reaktív lekérdezésekkel vagy eszközök közötti szinkronizációs követelményekkel rendelkező projektekben indokolt.

A választás az SQLite, Realm és Core Data között függ a platformtól, az objektummodell követelményeitől és a szinkronizációs stratégiától. Platformfüggetlen projektekhez (KMP, Flutter) az SQLite marad az egyetlen általános választás, ami minden célplatformon működik az adatmodell változtatása nélkül.

SQLite Androidon: Room és SQLiteOpenHelper

Room — egy Android Jetpack könyvtár, ami ORM-réteget biztosít az SQLite felett. A Room automatikusan generál SQL-lekérdezéseket a kommentált DAO-interfészekből, ellenőrzi a lekérdezések helyességét fordítási időben és támogatja az adatbázis-migrációkat a séma változásakor. A Room az ajánlott módja az SQLite-tal való munkának Androidon.

SQLiteOpenHelper — alacsony szintű API az SQLite közvetlen kezelésére ORM nélkül. Az osztály kezeli az adatbázis létrehozását, megnyitását és frissítését. Az SQLiteOpenHelper egyszerű SQL-lekérdezésekkel rendelkező projektekhez vagy amikor teljes kontroll szükséges az SQL-logika felett Room absztrakció nélkül.

Entitás és DAO példa Roomhoz

Az entitást Room-ban @Entity, a DAO-t @Dao annotációval jelöljük. A Room a kommentált metódusokat SQL-lekérdezésekké alakítja: az @Insert INSERT-t, az @Query SELECT-et generál a megadott SQL-lel. A migrációk Migration útján adhatók hozzá a régi és új sémaverzió megadásával. A Room ellenőrzi az SQL-t fordítási időben, ami kiküszöböli a szintaktikai hibákat éles környezetben.

@Entity
data class User(
    @PrimaryKey val id: Long,
    val name: String,
    @ColumnInfo(name = "created_at")
    val createdAt: Long
)

@Dao
interface UserDao {
    @Query("SELECT * FROM user ORDER BY name ASC")
    suspend fun getAllUsers(): List<User>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertUser(user: User)

    @Query("DELETE FROM user WHERE id = :id")
    suspend fun deleteUser(id: Long)
}

A Room automatikusan generálja a UserDao_Impl megvalósítást, ami futásidejű lekérdezéseket tartalmaz az SQLite-hoz a belső RoomDatabase-en keresztül. A korutinoknak (suspend) köszönhetően a DAO-metódusok aszinkron módon, háttérszálon hajthatók végre anélkül, hogy blokkolnák a UI-t. A Flow visszatérési típusok az @Query-ben automatikusan frissítik az eredményt a tábla változásakor.

SQLite iOS-en: FMDB és GRDB

FMDB — Objective-C burkoló az SQLite C API felett, történelmileg az első népszerű könyvtár iOS-re. FMDatabase és FMResultSet objektumokat biztosít lekérdezések végrehajtásához és eredmények lekéréséhez. Az FMDB egyszerű és minimalista, de nem támogatja a Swift-specifikus konstrukciókat — optionals, Codable, async/await.

GRDB — modern Swift könyvtár az SQLite-tal való munkához. Type-safe API-t, Codable-támogatást, Combine Publishers-t, async/await-t, migrációkat és valós idejű változáskövetést biztosít. A GRDB az új Swift-projektek számára előnyben részesítendő a Swift Concurrency-val való teljes integráció és a jobb kódolvashatóság miatt.

GRDB példa Swiftben

A GRDB táblákat Record osztályokon keresztül definiálja, amelyek megfelelnek a FetchableRecord és TableRecord protokolloknak. A lekérdezések Swiftben íródnak type-safe szintaxissal, nem nyers SQL-ben. A GRDB támogatja a DatabaseMigrator-t a séma verziózásához és az alkalmazásverziók közötti migrációkhoz.

struct User: Codable, FetchableRecord, TableRecord {
    var id: Int64
    var name: String
    var createdAt: Date
}

let dbPool = try DatabasePool(path: dbPath)
var migrator = DatabaseMigrator()
migrator.registerMigration("v1") { db in
    try db.create(table: "user") { t in
        t.autoIncrementedPrimaryKey("id")
        t.column("name", .text).notNull()
        t.column("createdAt", .datetime).notNull()
    }
}

let users = try await dbPool.read { db in
    try User.order(Column("name")).fetchAll(db)
}

A DatabasePool az SQLite WAL-módját használja egyidejű olvasáshoz. Több olvasó egyidejűleg férhet hozzá az adatbázishoz, míg egy író frissíti az adatokat WAL-on keresztül. A GRDB automatikusan kezeli a kapcsolatokat és tranzakciókat, biztosítva a szálbiztos hozzáférést az adatbázishoz bármely szálból kézi szinkronizáció nélkül.

Az SQLite teljesítményének optimalizálása

Indexek — a leghatékonyabb mód az SQLite-lekérdezések gyorsítására. Az index a WHERE, JOIN és ORDER BY részt vevő oszlopokon jön létre. Egy 100 000 rekordot tartalmazó tábla esetén az indexelt oszlopon való keresés másodpercek helyett ezredmásodpercekig tart. Az indexek azonban lassítják az INSERT és UPDATE műveleteket, ezért számukat egyensúlyban kell tartani az írás gyakoriságával.

Köteges beszúrás (batch insert) egyetlen tranzakció keretében győkeresen felgyorsítja a tömeges adatbetöltést. 1000 rekord egyenkénti beszúrása ~1 másodperc többletet jelent. Ugyanezen 1000 rekord egyetlen tranzakcióban — ~5–10 ezredmásodperc. A különbséget az magyarázza, hogy minden egyes INSERT új tranzakciót hoz létre szinkron lemezírással.

Teljesítmény-PRAGMA-k

PRAGMA — SQLite-parancsok a könyvtár viselkedésének beállítására. Kulcsfontosságú optimalizáló PRAGMA-k: PRAGMA synchronous=NORMAL (csökkenti az fsync gyakoriságát), PRAGMA cache_size=-8000 (8 MB gyorsítótárat foglal), PRAGMA temp_store=MEMORY (ideiglenes táblák a memóriában). Nagy adatmennyiséggel dolgozó mobilalkalmazások számára ezen PRAGMA-k kombinációja 2–3-szor gyorsítja a lekérdezéseket.

Egy másik fontos optimalizálás az SQL-lekérdezések előzetes fordítása (prepared statements). Ha egy lekérdezés többször is végrehajtódik (például 10 000 sor beszúrása), az SQL egyszeri fordítása és a statement használata 30–50%-kal csökkenti a CPU-terhelést. A Room és a GRDB automatikusan gyorsítótárazza a prepared statements-eket, de az SQLite C API közvetlen használatakor a fordítást kézzel kell végrehajtani.

class UserRepository(private val db: RoomDatabase) {

    suspend fun insertBatch(users: List<User>) {
        db.withTransaction {
            users.chunked(500).forEach { batch ->
                batch.forEach { user ->
                    insertUser(user)
                }
            }
        }
    }
}

A köteges beszúrás a withTransaction metódussal garantálja, hogy az összes INSERT egyetlen tranzakció keretében hajtódik végre. Részkötegekre bontás (chunked) megakadályozza a túl nagy tranzakciót, ami hosszú időre blokkolhatná a másik szálakat. Háttérszinkronizációhoz az 500 rekordos részköteg méret adja a sebesség és a UI-válaszadás optimális egyensúlyát.