SQLite vs Realm voor offline-first opslag in veldapps

Wat offline-first veldapps écht nodig hebben

Offline-first betekent niet alleen 'werkt zonder internet'. Het betekent dat de app nuttige data kan laden, nieuwe invoer kan accepteren en elke wijziging veilig bewaart totdat synchronisatie mogelijk is.

Veldwerk brengt een voorspelbare set beperkingen met zich mee: signaal valt in en uit, sessies zijn lang, apparaten kunnen oud zijn en energiebesparende modi zijn gebruikelijk. Mensen werken snel. Ze openen een klus, scrollen lange lijsten, maken foto’s, vullen formulieren in en gaan naar de volgende taak zonder over opslag na te denken.

Wat gebruikers opvalt is simpel. Ze verliezen vertrouwen wanneer bewerkingen verdwijnen, wanneer lijsten en zoeken traag zijn tijdens offline, wanneer de app niet duidelijk antwoordt op 'is mijn werk opgeslagen?', wanneer records dupliceren of ontbreken na het opnieuw verbinden, of wanneer een update vreemd gedrag veroorzaakt.

Daarom gaat de keuze tussen SQLite en Realm vooral over dagelijks gedrag, niet over benchmarks.

Voordat je een lokale database kiest, wees duidelijk over vier gebieden: je datamodel zal veranderen, je queries moeten bij echte workflows passen, offline sync creëert conflicten, en tooling bepaalt hoe snel je problemen in het veld kunt diagnosticeren.

1) Je data zal veranderen

Zelfs stabiele apps evolueren: nieuwe velden, hernoemde statussen, nieuwe schermen. Als modelwijzigingen pijnlijk zijn, lever je minder verbeteringen of loop je het risico echte apparaten met echte data te breken.

2) Queries moeten bij echte workflows passen

Veldapps hebben snelle filters nodig zoals 'vandaag's opdrachten', 'nabijgelegen locaties', 'niet-gesynchroniseerde formulieren' en 'items bewerkt in de laatste 2 uur'. Als de database die queries ongemakkelijk maakt, wordt de UI traag of verandert de code in een doolhof.

3) Offline sync creëert conflicten

Twee mensen kunnen hetzelfde record bewerken, of één apparaat kan oude data dagenlang bewerken. Je hebt een duidelijk plan nodig voor wat wint, wat samengevoegd wordt en wat menselijke besluitvorming vereist.

4) Tooling doet ertoe

Als er iets misgaat in het veld, moet je data kunnen inspecteren, bugs reproduceren en zonder giswerk begrijpen wat er gebeurde.

Migraties: het datamodel veranderen zonder gebruikers te breken

Veldapps blijven zelden hetzelfde. Na een paar weken voeg je een checkbox toe, hernoem je een status of splits je een 'notities'-veld in gestructureerde velden. Migraties zijn waar offline apps vaak falen, omdat de telefoon al echte data bevat.

SQLite slaat data op in tabellen en kolommen. Realm slaat data op als objecten met eigenschappen. Dat verschil wordt snel duidelijk:

• Met SQLite schrijf je meestal expliciete schemawijzigingen (ALTER TABLE, nieuwe tabellen, data kopiëren).
• Met Realm verhoog je meestal een schema-versie en voer je een migratiefunctie uit die objecten bijwerkt zodra ze worden aangeklikt.

Een veld toevoegen is in beide systemen makkelijk: voeg een kolom toe in SQLite, voeg een property met een default toe in Realm. Hernoemen en splitsen zijn de pijnlijke gevallen. In SQLite kan hernoemen beperkt zijn afhankelijk van je setup, dus teams maken vaak een nieuwe tabel en kopiëren data. In Realm lees je de oude property en schrijf je naar nieuwe properties tijdens migratie, maar je moet voorzichtig zijn met types, defaults en null-waarden.

Grote updates met on-device data vereisen extra voorzichtigheid. Een migratie die elk record herschrijft kan traag zijn op oudere telefoons, en een technicus wil niet vastzitten naar een laadindicator te kijken op een parkeerplaats. Plan migratietijd en overweeg zware transformaties over meerdere releases te spreiden.

Om migraties eerlijk te testen, behandel ze zoals sync:

• Installeer een oude build, maak realistische data aan en upgrade dan.
• Test met kleine en grote datasets.
• Kill de app halverwege een migratie en start opnieuw.
• Test scenario's met weinig opslag.
• Ga ervan uit dat je vooruit kunt migreren, ook al kun je niet terug.

Voorbeeld: als 'equipmentId' 'assetId' wordt en later splitst in 'assetType' plus 'assetNumber', dan moet de migratie oude inspecties bruikbaar houden, en niet afdwingen dat gebruikers uitloggen of hun data wissen.

Queryflexibiliteit: wat je uit je data kunt vragen

Veldapps leven of sterven op lijstschermen: vandaag's opdrachten, nabijgelegen assets, klanten met open tickets, onderdelen gebruikt deze week. Je opslagkeuze moet die vragen gemakkelijk te uiten, snel uit te voeren en over zes maanden moeilijk te mislezen maken.

SQLite geeft je SQL, nog steeds de meest flexibele manier om grote datasets te filteren en sorteren. Je kunt condities combineren, joinen over tabellen, resultaten groeperen en indexes toevoegen wanneer een scherm langzaam wordt. Als je app 'alle inspecties voor assets in Regio A, toegewezen aan Team 3, met elk mislukt checklist-item' nodig heeft, kan SQL dat meestal netjes uitdrukken.

Realm vertrouwt op objecten en een hoger niveau query-API. Voor veel apps voelt dit natuurlijk: query Job-objecten, filter op status, sorteer op vervaldatum, volg relaties naar gerelateerde objecten. Het compromis is dat sommige vragen die triviaal zijn in SQL (vooral rapportage-achtige queries over meerdere relaties) moeilijker uit te drukken zijn, of dat je data moet herschikken zodat het past bij de queries die je nodig hebt.

Zoeken en relaties

Voor gedeeltelijke tekstzoekopdrachten over meerdere velden (jobtitel, klantnaam, adres) duwt SQLite je vaak naar zorgvuldige indexering of een speciale full-text aanpak. Realm kan ook tekst filteren, maar je moet nog steeds nadenken over performance en wat 'contains' betekent op schaal.

Relaties zijn een ander praktisch pijnpunt. SQLite behandelt one-to-many en many-to-many met join-tabellen, wat patronen zoals 'assets getagd met deze twee tags' overzichtelijk maakt. Realm-links zijn makkelijk te navigeren in code, maar many-to-many en 'query doorheen' patronen hebben meestal meer planning nodig om reads snel te houden.

Raw queries vs leesbaar onderhoud

Een onderhoudsvriendelijk patroon is om een kleine set benoemde queries te houden die direct map naar schermen en rapporten: je hoofdlijstfilters en sorteringen, een detailview-query (één record plus gerelateerde records), de zoekdefinitie, een paar tellers (badges en offline totalen) en export/rapportage queries.

Als je frequente ad-hocvragen van het bedrijf verwacht, is de raw query-kracht van SQLite moeilijk te verslaan. Als je wilt dat data-access leest als werken met normale objecten, kan Realm sneller aanvoelen om te bouwen, zolang het je moeilijkste schermen zonder onhandige omwegen kan beantwoorden.

Conflictresolutie en sync: welke ondersteuning je krijgt

Offline-first veldapps ondersteunen meestal dezelfde kernacties tijdens disconnectie: maak een record, werk een record bij, verwijder iets ongeldig. Het moeilijke is niet lokaal opslaan. Het moeilijke is beslissen wat er gebeurt als twee apparaten hetzelfde record veranderen voordat er gesynchroniseerd is.

Conflicten verschijnen in eenvoudige situaties. Een technicus werkt een inspectie bij op een tablet in een kelder zonder signaal. Later corrigeert een supervisor dezelfde inspectie vanaf een laptop. Wanneer beide weer verbinden, ontvangt de server twee verschillende versies.

De meeste teams kiezen één van deze benaderingen:

• Last write wins (snel, maar kan goede data stilletjes overschrijven)
• Merge per veld (veiliger wanneer verschillende velden veranderen, maar heeft duidelijke regels nodig)
• Handmatige review-queue (traagst, beste voor risicovolle wijzigingen)

SQLite geeft je een betrouwbare lokale database, maar levert geen sync. Je bouwt meestal de rest: houd pending operaties bij, stuur ze naar een API, retry veilig en handhaaf conflictregels op de server.

Realm kan de hoeveelheid plumbing verminderen als je zijn sync-functies gebruikt, omdat het is ontworpen rond objecten en change-tracking. Maar 'ingebouwde sync' kiest nog steeds niet jouw bedrijfsregels. Jij beslist wat telt als conflict en welke data mag winnen.

Plan vanaf dag één een audit trail. Veldteams moeten vaak duidelijk antwoord hebben op 'wie heeft wat wanneer en vanaf welk apparaat gewijzigd'. Zelfs als je last write wins kiest, sla metadata op zoals user ID, device ID, tijdstempels en (indien mogelijk) een reden. Als je backend snel gegenereerd is, bijvoorbeeld met een no-code platform zoals AppMaster, kun je eerder itereren op deze regels voordat je honderden offline-apparaten in het veld hebt.

Debugging en inspectie: problemen opvangen voordat het veld dat merkt

Offline-bugs zijn lastig omdat ze gebeuren wanneer je niet kunt zien hoe de app met een server praat. Je debug-ervaring komt vaak neer op één vraag: hoe makkelijk kun je zien wat er op het apparaat staat en hoe het over tijd veranderde?

SQLite is makkelijk te inspecteren omdat het een bestand is. In ontwikkeling of QA kun je de database van een testapparaat halen, openen met gangbare SQLite-tools, ad-hoc queries draaien en tabellen exporteren naar CSV of JSON. Dit helpt je te bevestigen 'welke rijen bestaan' versus 'wat de UI toont.' Het nadeel is dat je je schema, joins en eventuele migratie-scaffolding die je maakte, moet begrijpen.

Realm kan 'app-achtiger' aanvoelen om te inspecteren. Data staat als objecten en de tooling van Realm is vaak de makkelijkste manier om klassen, properties en relaties te bekijken. Het is goed om objectgrafproblemen te spotten (missende links, onverwachte nulls), maar ad-hoc analyse is minder flexibel als je team gewend is aan SQL-gebaseerde inspectie.

Loggen en offline-problemen reproduceren

De meeste veldfouten komen neer op stille schrijferrors, gedeeltelijke sync-batches of een migratie die half-af is gebleven. Investeer in een paar basics: per-record 'last changed' tijdstempels, een device-side operation log, gestructureerde logs rond migraties en achtergrondschrijfsessies, een manier om uitgebreide logging in QA-builds aan te zetten en een 'dump en deel' actie die een geredigeerde snapshot exporteert.

Voorbeeld: een technicus meldt dat voltooide inspecties verdwijnen na een batterij-ontlading. Een gedeelde snapshot helpt je bevestigen of records nooit geschreven zijn, wel geschreven maar niet opgehaald zijn, of bij het opstarten zijn teruggedraaid.

Het delen van een falende snapshot

Bij SQLite is delen vaak zo simpel als het .db-bestand delen (plus eventuele WAL-bestanden). Bij Realm deel je typisch het Realm-bestand samen met bijbehorende sidecar-bestanden. In beide gevallen, definieer een herhaalbaar proces om gevoelige data te verwijderen voordat iets het apparaat verlaat.

Betrouwbaarheid in de echte wereld: fouten, resets en upgrades

Veldapps falen op saaie manieren: de batterij gaat leeg tijdens opslaan, het OS killt de app op de achtergrond, of opslag raakt vol na weken met foto's en logs. Je lokale databasekeuze beïnvloedt hoe vaak die fouten leiden tot verloren werk.

Als een crash gebeurt halverwege een write, kunnen zowel SQLite als Realm veilig zijn als ze correct worden gebruikt. SQLite is betrouwbaar wanneer je wijzigingen in transacties wikkelt (WAL-mode kan helpen met veerkracht en snelheid). Realm-writes zijn standaard transactioneel, dus je krijgt meestal 'alles of niets' saves zonder extra werk. Het gemeenschappelijke risico is niet de database-engine, maar app-code die in meerdere stappen schrijft zonder een duidelijk commitpunt.

Corruptie is zeldzaam, maar je hebt een recovery-plan nodig. Met SQLite kun je integriteitschecks draaien, herstellen vanaf een bekende goede backup of herbouwen vanuit een server-resync. Bij Realm betekent corruptie vaak dat het hele Realm-bestand verdacht is, dus de praktische recovery-route is vaak 'drop local en resync' (prima als de server de bron van waarheid is, pijnlijk als het apparaat unieke data heeft).

Opslaggroei is een andere verrassing. SQLite kan opzwellen na deletes tenzij je periodiek VACUUM draait. Realm kan ook groeien en heeft compaction-policies nodig, plus het periodiek opruimen van oude objecten (zoals voltooide jobs) zodat het bestand niet eeuwig blijft groeien.

Upgrades en rollbacks zijn een andere valkuil. Als een update het schema of opslagformaat verandert, kan een rollback gebruikers achterlaten met een nieuwere file die ze niet kunnen lezen. Plan upgrades als éénrichting, met veilige migraties en een 'reset lokale data' optie die de app niet breekt.

Betrouwbaarheidsgewoonten die zich uitbetalen:

• Handel 'schijf vol' en schrijf-fouten af met een duidelijke boodschap en een retry-pad.
• Sla gebruikersinvoer op in checkpoints, niet alleen aan het einde van een lang formulier.
• Houd een lichtgewicht lokale audit-log voor recovery en support.
• Snoei en archiveer oude records voordat de database te groot wordt.
• Test OS-upgrades en background kills op low-end apparaten.

Voorbeeld: een inspectie-app die checklists en foto's opslaat kan binnen een maand weinig opslag bereiken. Als de app vroegtijdig lage ruimte detecteert, kan hij fotograferen pauzeren, uploaden wanneer mogelijk en checklist-saves veilig houden, ongeacht welke lokale database je gebruikt.

Stapsgewijs: hoe je je opslagaanpak kiest en instelt

Behandel opslag als onderdeel van het product, niet als een bibliotheekkeuze. De beste optie is die welke de app bruikbaar houdt wanneer het signaal wegvalt, en voorspelbaar wanneer het terugkomt.

Een eenvoudig besluitpad

Schrijf eerst je offline gebruikersflows op. Wees specifiek: 'open vandaag's opdrachten, voeg notities toe, voeg foto's toe, markeer voltooid, neem een handtekening'. Alles op die lijst moet elke keer zonder netwerk werken.

Werk dan een korte volgorde door: noem offline-kritieke schermen en hoeveel data elk nodig heeft (vandaag's opdrachten versus geschiedenis), schets een minimaal datamodel en de relaties die je niet kunt faken (Job -> ChecklistItems -> Answers), kies een conflictregel per entiteit (niet één regel voor alles), beslis hoe je fouten test (migraties op echte apparaten, sync-retries, geforceerd uitloggen/herinstalleren gedrag), en bouw een klein prototype met realistische data die je kunt timen (laden, zoeken, opslaan, sync na een dag offline).

Dat proces onthult meestal de echte beperking: heb je flexibele ad-hoc queries en makkelijke inspectie nodig, of geef je de voorkeur aan object-gebaseerde toegang en strakkere modelhandhaving?

Wat je in het prototype moet valideren

Gebruik één realistisch scenario, zoals een technicus die 30 inspecties offline afrondt en daarna terugrijdt naar dekking. Meet first-load tijd met 5.000 records, of een schemawijziging een update overleeft, hoeveel conflicten verschijnen na reconnect en of je elk conflictoplossing kunt uitleggen, en hoe snel je een 'slecht record' kunt inspecteren wanneer support belt.

Als je stromen snel wilt valideren voordat je je vastlegt, kan een no-code prototype in AppMaster je helpen de workflow en het datamodel vroeg vast te leggen, zelfs voordat je de on-device databasekeuze finaliseert.

Veelgemaakte fouten die offline-first apps schaden

De meeste offline-first mislukkingen komen niet door de database-engine. Ze komen doordat men saaie onderdelen overslaat: upgrades, conflictregels en duidelijke foutafhandeling.

Een valkuil is aannemen dat conflicten zeldzaam zijn. In veldwerk zijn ze normaal: twee technici bewerken hetzelfde asset, of een supervisor wijzigt een checklist terwijl een apparaat offline is. Als je geen regel definieert (last write wins, merge per veld of beide versies bewaren), overschrijf je uiteindelijk echt werk.

Een andere stille fout is het zien van het datamodel als 'klaar' en geen migratie-oefeningen doen. Schemawijzigingen gebeuren zelfs in kleine apps. Als je je schema niet versioneert en upgrades vanaf oudere builds niet test, kunnen gebruikers na een update vastlopen met mislukte migraties of lege schermen.

Prestatieproblemen duiken ook laat op. Teams downloaden soms alles 'voor het geval', en vragen zich dan af waarom zoeken traag is en de app minuten nodig heeft om te openen op een mid-range telefoon.

Patronen om op te letten:

• Geen geschreven conflictbeleid, waardoor bewerkingen stilletjes worden overschreven.
• Migraties die werken op verse installs maar falen bij echte upgrades.
• Offline caching die onbeperkt groeit en queries traag maakt.
• Sync-fouten verborgen achter een spinner, waardoor gebruikers denken dat data verzonden is.
• Debuggen op gevoel in plaats van een herhaalbaar repro-script en sample data.

Voorbeeld: een technicus voltooit offline een inspectie, tikt op Sync en krijgt geen bevestiging. De upload faalt vanwege een auth-token probleem. Als de app de fout verbergt, gaat hij weg en denkt dat de klus klaar is, en vertrouwen is weg.

Wat je opslag ook kiest, voer een basis 'veldmodus'-test uit: vliegtuigstand, lage batterij, app-update en twee apparaten die hetzelfde record bewerken. Als je snel bouwt met een no-code platform zoals AppMaster, bouw deze tests in het prototype voordat de workflow een groter team bereikt.

Snelle checklist voordat je je vastlegt

Voordat je een opslagengine kiest, definieer wat 'goed' betekent voor je veldapp en test het met echte data en echte apparaten. Teams discussiëren over features, maar de meeste fouten komen door basics: upgrades, trage schermen, onduidelijke conflictregels en geen manier om lokale staat te inspecteren.

Gebruik dit als go/no-go poort:

• Bewijs upgrades: neem minstens twee oudere builds, upgrade naar de huidige build en bevestig dat data nog opent, bewerkt en synchroon loopt.
• Houd kernschermen snel bij reëel volume: laad realistische data en meet de traagste schermen op een mid-range telefoon.
• Schrijf conflictbeleid per recordtype: inspecties, handtekeningen, gebruikte onderdelen, opmerkingen.
• Maak lokale data inspecteerbaar en logs verzamelbaar: definieer hoe support en QA staat vangen wanneer offline.
• Maak herstel voorspelbaar: beslis wanneer je cache herbouwen, opnieuw downloaden of opnieuw inloggen vereist. Maak 'app herinstalleren' niet het plan.

Als je prototype in AppMaster loopt, pas dezelfde discipline toe. Test upgrades, definieer conflicten en oefen recovery voordat je naar een team gaat dat downtime niet kan veroorloven.

Voorbeeldscenario: een inspectie-app voor technici met slecht signaal

Een veldtechnicus begint de dag door 50 werkorders naar zijn telefoon te downloaden. Elke klus bevat adres, benodigde checklist-items en een paar referentiefoto's. Daarna valt het signaal de hele dag in en uit.

Tijdens elk bezoek bewerkt de technicus dezelfde paar records herhaaldelijk: jobstatus (Aangekomen, Bezig, Klaar), gebruikte onderdelen, klanthandtekening en nieuwe foto's. Sommige bewerkingen zijn klein en frequent (status). Andere zijn groot (foto's) en mogen niet verloren gaan.

Het sync-moment: twee mensen hebben dezelfde klus aangeraakt

Om 11:10 markeert de technicus Job #18 als Klaar en voegt een handtekening toe terwijl hij offline is. Om 11:40 herverdeelt een dispatcher Job #18 omdat het er nog open uitziet op kantoor. Als de technicus om 12:05 weer verbinding heeft, uploadt de app de wijzigingen.

Een goede conflictflow verbergt dit niet. Hij toont het. Een supervisor zou een eenvoudige melding moeten zien: 'Er bestaan twee versies van Job #18', met belangrijke velden naast elkaar (status, toegewezen technicus, tijdstempel, handtekening ja/nee) en duidelijke opties: behoud veldupdate, behoud kantoorupdate of merge per veld.

Hier komen opslag- en sync-beslissingen in de echte wereld naar voren: kun je een schone geschiedenis van wijzigingen bijhouden en die veilig herhalen na uren offline?

Wanneer een klus 'verdwijnt' gaat debugging meestal over aantonen wat er gebeurde. Log genoeg om te antwoorden: lokale record-ID en server-ID mapping (inclusief wanneer het gemaakt is), elke write met tijdstempel/user/device, syncpogingen en foutmeldingen, conflictbeslissingen en de winnaar, en foto-uploadstatus apart bijgehouden van het klusrecord.

Met die logs kun je het probleem reproduceren in plaats van te gissen op basis van een klacht.

Volgende stappen: valideer snel, bouw dan de volledige veldoplossing

Voordat je partij kiest in SQLite vs Realm discussies, schrijf een eendelige specificatie voor je offline flows: de schermen die een technicus ziet, welke data op het apparaat leeft en wat zonder signaal moet werken (aanmaken, bewerken, foto's, handtekeningen, in de wachtrij geplaatste uploads).

Bouw daarna vroeg een prototype van het hele systeem, niet alleen de database. Veldapps falen op de naden: een mobiel formulier dat lokaal opslaat helpt niet als het admin-team records niet kan bekijken en herstellen, of als de backend updates later verwerpt.

Een praktisch validatieplan:

• Bouw een dun end-to-end deel: één offline formulier, één lijstweergave, één sync-poging, één adminscherm.
• Voer een wijzigingstest uit: hernoem een veld, splitst één veld in twee, ship een testbuild en zie hoe de upgrade zich gedraagt.
• Simuleer conflicten: bewerk hetzelfde record op twee apparaten, sync in verschillende volgordes en noteer wat breekt.
• Oefen velddebugging: beslis hoe je lokale data, logs en mislukte sync-payloads op een echt apparaat inspecteert.
• Schrijf een resetbeleid: wanneer wis je lokale cache en hoe herstellen gebruikers zonder werk te verliezen.

Als snelheid belangrijk is, kan een no-code first-pass je helpen de workflow snel te valideren. AppMaster (appmaster.io) is een optie om vroeg het volledige systeem te bouwen (backend-services, een web adminpaneel en mobiele apps) en vervolgens schone broncode te genereren terwijl eisen veranderen.

Kies de volgende validatiestap op basis van risico. Als formulieren wekelijks veranderen, test migraties eerst. Als meerdere mensen dezelfde klus aanraken, test conflicten. Als je bang bent voor 'het werkte op kantoor', geef prioriteit aan je velddebugging-workflow.