Engineering
Studio
By industry · 12
Veodar
Technology · On-device database
SQLite is a complete database that lives inside the app itself, in a file on the device. With it the app stores, searches and calculates without depending on coverage, and sends the changes when the connection returns. We design that local data model, the sync with your server and what it takes for nothing to get lost on the way.
Often combined with
Situations
Storing on the device pays off when work can't stop because the network fails: in a basement, in a warehouse, in the field or on a plane.
Today every screen asks the server for its data and, with no network, there is no app. With the data on the device the work goes on and is sent later.
Two people edit the same thing, or a send is cut off halfway. Each change is noted in a queue with its order and applied only once, with a clear rule for conflicts.
Catalogs, customers or histories that are downloaded every time today. Stored on the device, with their indexes, they are searched at once and without using data.
Customer data, signatures or photos that must not stay readable if the device is lost. The database is encrypted and the key is kept where the system protects it.
Services
Four kinds of job. The first two are almost always one: storing on the device forces a decision on how it syncs.
Module 1 · DrawersThe tables the app needs to work alone: what is downloaded, what is created on the device and how it relates. With writes that complete in full or not at all.
Examples of deliverables
Module 2 · BarrierA queue of pending changes that goes out when there is network, retries if it fails and doesn't duplicate. And a written rule for conflicts: who wins, or when a person is asked.
Examples of deliverables
Module 3 · IndexIndexes so long lists answer at once, text search inside the records and the calculations asked of the server today, done on the device itself.
Examples of deliverables
Module 4 · LockThe database encrypted, structure changes between app versions without losing what is stored, and a way to recover the data if a device fails before syncing.
Examples of deliverables
A working example
Working example on made-up data. Turn coverage off, close a report and add another: they are saved on the phone and wait in the queue. Turn it back on and watch them leave, and what happens when the office has touched the same report.
Connection
The office, meanwhile
Rule on a conflict
Change queue
On the phone (SQLite)
| Report | Status | Sent |
|---|
At the office (simulated)
| Report | Status |
|---|
This example's database lives in your browser's memory and the office is simulated: nothing is sent. The order of the operations, the queue and the conflict rule are the ones programmed in a real app.
Integration
The database on the device doesn't replace your company's: it is a working copy of the part each person needs. The truth still lives on your server.
Where it comes from
Where it goes
How we work and what we deliver
We look at which data the app handles, where it comes from, who changes it and what fails today when there is no network.
We write down what is stored on the device, how it syncs, which rule settles conflicts and what stays out.
The main flow working offline on your devices, with the change queue in view.
You test it in airplane mode, with cuts in the middle of a send and with two people changing the same record.
The data model, the conflict rule, how it migrates between versions and how data is recovered from a device.
Questions
Missing yours? Write it to info@veodar.com and we'll reply with a specific question, not a brochure.
It is a complete relational database, with SQL queries, transactions and indexes. What sets it apart is that it needs no server: it is a library inside the app and a file on the device. That is why it is the one iPhone and Android themselves use inside.
No. SQLite stores and queries; sending changes to your server and receiving its own has to be designed. It is the part that needs most care and the one that decides whether an offline app can be trusted, so it is defined and tested before the screens.
It depends on the rule that was written, and you decide that rule with us: the last change wins, the office wins, fields are merged one by one or the app asks. What can't happen is that one of the two changes disappears without anyone knowing.
If the database is encrypted and the key is kept in the system's protected store, what is saved can't be read without unlocking the device. We also decide which data should not stay on the device longer than needed.
Far more than an app usually needs: the practical limit is the free space on the device, not SQLite. What is worth limiting is what gets downloaded, because there is no point carrying on the phone what that person won't use.
Yes. There are mature libraries for React Native, for Swift and for Kotlin, and it is also the usual database in desktop applications. The data model and the sync rule are designed the same way; what changes is the library that runs them.
Updated:
Related services
Other technologies
Get started
Knowing which work stops when the network fails and which data is involved is enough for a first answer.
What helps us assess it
Before you write, see how we price a project or our solutions by department.
Cookies
We store your language and this choice so the site works. With your permission, we measure visits and speed anonymously, with no tracking cookies or advertising.
Cookies
Necessary
Your language, this choice and spam protection on the contact form.
Anonymous measurement
Page views and load times, in aggregate, through Vercel. No cookies, no tracking across sites.