DEV Community: Vlad (Volodymyr Shiyan)

Building Offline-First Invoicing Software: Why Local Storage Matters for Freelancers

Vlad (Volodymyr Shiyan) — Fri, 16 Oct 2026 02:40:26 +0000

This article was originally published on the LockMargin blog. I'm Vlad Shiyan, founder and developer of LockMargin — a local-first Financial OS for freelancers who are tired of renting their tools. Below is a technical deep-dive into the architecture choices behind the product.

Most freelancers don't fully control the software that runs their business. Invoices, client lists, payment history — a lot of it sits on someone else's servers. Access often depends on a monthly payment and a working internet connection. Moving away later can turn into a bigger headache than expected.

I built LockMargin around one question: what should a freelancer actually own? This guide walks through the main models, the features that matter, and the real trade-offs. I'm not here to crown a winner. I just want you to choose with your eyes open.

If the ownership angle interests you, start with The Ownership Manifesto.

What Makes Invoicing Software Different for Freelancers?

A company with an accounting team and a solo freelancer both need invoices. Their daily reality looks nothing alike.

A bigger company needs roles, approval chains, consolidated reports, and integrations across departments. A freelancer usually needs to create an invoice, mark a payment, check what's still outstanding, and get back to paid work.

That difference changes what "good software" means.

Useful priorities for most freelancers:

Speed — routine invoices should take minutes, not a long setup ritual
Predictable cost — the price should make sense for a one-person business
Reliable records — client details, amounts, dates, and status should stay consistent
Portability — you should be able to back up and move your data without drama
Privacy — you should know where the data lives and who can see it
A workflow that doesn't feel like learning an enterprise platform

Subscriptions aren't automatically bad. They can cover hosting, collaboration, support, and ongoing development. Cloud access across devices is genuinely useful for some people.

The question is whether those benefits justify the cost and the dependency for your work.

Someone who works with an assistant across several devices may prefer a hosted tool. Someone who works alone on one Windows machine may prefer desktop software with local storage and full control over backups.

Neither choice is more professional. The right one simply fits how you actually work.

Key Features Worth Checking

Before you compare brands, write down the tasks you do every week.

At minimum you need client records, line items, totals, payment terms, due dates, a way to export invoices, and a way to record payments. Depending on your work you may also want recurring invoices, expense tracking, tax fields, multi-currency support, or project-level reporting.

Then look at the parts that usually get glossed over.

Offline-First Architecture

"Offline" means different things in different products.

Some tools let you view a cached invoice without internet. Others let you create records locally and sync later. A few are designed so the local database is the real working copy.

Those are different architectures.

With a true local-first desktop app, the data lives on your machine. You can create and edit invoices without waiting for a server. Internet is only needed for the rare things you choose to do online.

Check these points:

Can you create and edit records while completely offline?
Where is the primary copy of the data stored?
Does the app need periodic online authentication?
What happens when you reconnect?
Can you export everything without going through a cloud service?
How do backups and restores actually work?

Local storage has trade-offs. If your computer dies and you have no usable backup, the records are gone. A cloud service may handle some of that for you — but you still need to understand its retention and recovery rules.

Offline-first is not a substitute for backups. It just changes who controls the working data.

More detail on how LockMargin handles this: Security.

One-Time Payment vs Subscription

A subscription spreads the cost. A one-time licence puts more of it upfront and can make future spending easier to predict.

Neither model tells the full story. Compare the total cost over the time you expect to use the tool, including any extra fees for users, exports, or support.

Example with a $19/month subscription:

Period	Subscription ($19/mo)	One-time licence ($49)
1 year	$228	$49
3 years	$684	$49
5 years	$1,140	$49

These numbers only compare the stated software prices. They ignore taxes, optional services, and any future upgrades.

Ask four practical questions:

Is the recurring fee mandatory?
What stops working if I cancel?
Can I still access and export my records after cancellation?
What updates and support are actually included?

A one-time payment doesn't magically guarantee lifetime updates or compatibility with every future operating system. Read the licence.

LockMargin Standard is $49 once. The point is predictable pricing and local control — not a claim that software never needs maintenance.

Current terms: Pricing.

Data Ownership and Privacy

Your invoices and client records are business assets. Choosing software means choosing how those assets are stored, protected, and retrieved.

Three separate things matter:

Legal ownership — what the agreements and applicable law say
Technical control — where the data physically lives and who can reach it
Portability — whether you can get the data out and use it elsewhere

A product can give you export rights while still keeping the primary copy on its servers. Another can store data locally but make export painful. You need all three to be solid.

Look for clear answers:

Can I export client and invoice records in a documented format?
Does the export include the fields I actually need, or just a PDF?
Can I back everything up and restore it on another machine?
Is sensitive data encrypted at rest?
How are the encryption keys protected?
Does the app collect telemetry, and can I turn it off?
What data, if any, leaves my computer during normal use?

CSV and JSON are useful for moving records. SQLite is useful when the local database is well documented. A PDF is fine for sending an invoice — it is not a substitute for a full export.

Encryption needs precision. AES-256-GCM is an authenticated encryption algorithm. Argon2id is a password-hashing and key-derivation function. What matters is how the application uses them, protects the keys, and handles recovery if you forget the password.

No model removes every risk. Local software can still be hit by malware or a stolen laptop. Cloud software can offer strong access controls and managed recovery. Choose the risks you understand and can live with.

LockMargin's approach is described in Security. The reasoning behind it is in The Ownership Manifesto.

Multi-Currency Support

If you work with clients in different countries, currency handling is not a nice-to-have.

A good tool lets you set the invoice currency, show amounts clearly, and keep the values the client agreed to. You may also need the exchange rate recorded for your own bookkeeping.

Check:

Can you set a default currency per client?
Can an invoice use a different currency from your usual one?
Is the exchange rate stored, and can you see its source and date?
Are the original amounts preserved if rates change later?
Can you tell the invoiced amount from the amount you actually received?

An exchange rate that changes after the invoice is issued should not silently rewrite history. LockMargin's approach is called Snapshot Billing: the relevant billing values are frozen at the moment the invoice is created. See the current implementation on Features.

Immutable Invoices

An invoice is a business record. Once you've sent it, you should be able to show exactly what it said.

Legal requirements for invoices, corrections, and credit notes differ by country. There is no universal workflow that satisfies every jurisdiction. Check the rules that apply to you.

From a software point of view, look for a clear distinction between draft and issued. After issuance, changing the original record should be hard or impossible without leaving a clear trail.

You should be able to answer:

Which version was issued?
When?
What amount and currency did it show?
Was it paid, partially paid, or still open?
If a correction was needed, how was it documented?

Sometimes the right move is a credit note or a formal replacement. Simply editing the old invoice is not always acceptable.

An audit trail only helps if it is complete and protected against casual changes. More on how LockMargin handles this: Features.

Cloud vs Desktop: Which Model Fits You?

The choice comes down to how you work, how much risk you accept, and how much control you want.

Consideration	Cloud software	Desktop software
Access	Often available on any device	Usually tied to the installed computer
Internet	Commonly required for full use	Can work offline if designed for it
Collaboration	Usually easier for teams	Often needs a separate sharing process
Backups	Often handled by the provider	Usually your responsibility
Data location	Typically on provider infrastructure	Can be fully local
Pricing	Often subscription	May offer a one-time licence
Maintenance	Provider handles most infrastructure	You handle install, updates, and recovery

These are tendencies, not hard rules. Some cloud tools have solid offline features and good exports. Some desktop tools still depend on online services. Judge the actual product.

When Cloud Makes Sense

Cloud is often the better fit if several people need to work on the same records, you switch devices constantly, or you rely on integrated payment and accounting services.

The monthly cost can be reasonable if it replaces work you would otherwise have to do yourself. Managed backups and support can also be worth paying for — as long as you understand their limits.

Before you commit, check cancellation terms, export quality, data retention, and what happens if the provider changes pricing or shuts down the product.

When Desktop Makes Sense

Desktop software often fits better if you work alone, mostly on one computer, and want direct control over your records.

It can reduce dependence on internet access and remote infrastructure. A one-time licence can make the cost more predictable.

The trade-off is responsibility. You need a backup routine and a recovery plan. If you expect real-time collaboration, check whether a desktop workflow can actually support it.

The Offline-First Hybrid

Some desktop tools keep the primary records local and let you export or copy them wherever you want. That is different from automatic cloud sync. Copying a database file to Dropbox is not the same as safe multi-device synchronisation. Simultaneous edits can create conflicts.

Choose the model that matches how you actually work. For a concrete comparison of one cloud option, see LockMargin vs FreshBooks.

How to Choose the Right Invoicing Software

You don't need to compare every feature of every product. Start with the requirements that would make a tool unusable for you.

Decide how you need to access your records. One computer or several devices and collaborators? Be honest.
Check the complete cost. Look at one, three, and five years. Include mandatory add-ons and what happens if you cancel.
Test the export. Create sample clients and invoices, export them, and open the files. Check dates, currencies, line items, and payment status. A button labelled "Export" doesn't tell you enough.
Test backup and recovery. Find out how to back up and restore. If the data is local, keep a copy somewhere other than the main machine. If the provider manages backups, check retention and restore procedures.
Verify the billing workflow. Create a test invoice, issue it, then check how corrections are handled. Make sure you can still retrieve the original amount and status later.
Review security and privacy. Read the privacy policy and technical docs. Look for concrete answers about storage, encryption, key management, and telemetry. Vague assurances are not enough.
Check the limitations. Supported operating systems, currency features, licensing terms, and support. A tool can be excellent without supporting every platform — as long as its limits don't conflict with your needs.

Finally, run a realistic test. Add a client, create an invoice, record a payment, export everything. You'll learn more in fifteen minutes than from any feature list.

Getting Started: Your First Invoice in Five Steps

Once you've chosen the software, the basic loop is simple. Labels differ, but the steps are the same.

Step 1: Enter your business details

Add whatever your invoices legally need — name, address, tax ID, payment instructions. Check the rules that apply to you.

Step 2: Add the client

Name, contact details, currency, payment terms. Don't assume every client will use the same settings.

Step 3: Create the invoice

Clear description of the work, quantities, rates, taxes, due date. Review the totals before you issue it.

Step 4: Send or export

PDF or email, depending on the tool. Check the finished document — client details, invoice number, currency, totals, payment instructions. Keep a copy of what you sent.

Step 5: Record the payment and back up

Update the status when money arrives. If the client pays in instalments, keep the remaining balance clear. Then make sure your records are backed up.

Conclusion: Own Your Tools, Own Your Business

The best invoicing software for freelancers is not the one with the longest feature list. It's the one that fits your actual workflow, protects the records you depend on, and makes the costs and trade-offs clear.

Cloud tools can be excellent for collaboration and multi-device access. Desktop tools can give simpler local control and more predictable pricing. Offline-first software makes working without a constant connection practical — but you still need a sensible backup plan.

The questions that matter are straightforward:

Where does the data live?
Can you get it out?
What happens when you stop paying?
Can you prove what you sent?
Are you paying for features that actually help you?

I built LockMargin because I wanted more control over the tools behind my own work. It is currently Windows-first. There is no mobile app yet. The Standard licence is $49 once. Those details matter when you decide whether it fits your setup.

If local-first invoicing matches the way you work, take a look at Download and the current Pricing.

Own your tools. Don't rent them by default.

Why I published the format before the product

Vlad (Volodymyr Shiyan) — Mon, 28 Sep 2026 16:13:40 +0000

The data layer is open before the product launches. Here is why I made the schema, export formats, and decryption tool public first.

The promise that required proof

LockMargin's core promise is simple: your business keeps working even if I disappear. No license server, no account, no phone-home. The license is a signed token the app verifies offline; the token carries no expiration date.

But a promise without evidence is marketing. The honest ceiling post showed what happens when someone tries to pirate the binary — the check can be patched, the key can leak, the shell can be copied. The asymmetry that actually protects the user is not the binary. It is the data.

A cracked LockMargin is a shell. What a freelancer keeps in it — five years of invoices, clients, time entries — lives in an open SQLite format whose spec is public. The value isn't in my code staying secret. It is in the records staying readable, verifiable, and theirs.

What is open today

The data layer went public in September 2026, before Early Access opened and before the first customer paid: github.com/vladsh444/lockmargin-data-layer under MIT license.

The repository contains:

The SQLite schema the app uses today — 33 tables across 4 groups, reconstructed from the application documentation
Plaintext export formats (CSV, JSON) with full fidelity
The encrypted .lockmargin container format specification
A reference decrypt-cli in pure Python — no dependencies, verifiable round-trips
Sample databases generated from the same schema the app uses

The decrypt-cli and scripts/build_sample.py reproduce the schema verbatim in their own SCHEMA constant, so the documentation, the samples, and the round-trip verification always agree.

Why before launch

Three reasons.

Trust is earned before the first payment. A freelancer evaluating LockMargin can verify today — without buying, without trusting me — that their data will never be trapped. They can run the decrypt tool on a sample file. They can read the schema. They can write their own importer. The proof exists before the ask.

The format is the product. In a local-first tool, the file format is the API. It is the migration path, the backup strategy, the integration surface, the exit door. Shipping the format late means shipping the product without its most important interface. Shipping it first means the interface is battle-tested by the time the first customer depends on it.

Community review catches mistakes I would miss. The schema has been public since August. Reviewers outside the project have already spotted edge cases in the encryption envelope and the export normalization; both fixes are in the app before Early Access, and the round-trip tools above are how I verify them.

The cost of waiting

The alternative — keeping the format private until after launch — buys a false sense of control. It delays the only proof that matters: can a third party read the data without the app? If the answer is no, the promise is fiction. If the answer is yes, publishing early only accelerates the verification.

There is no competitive moat in a SQLite schema, and publishing it means giving up some control: someone can build a reader, an exporter, even a competing client around the same data. That is not a bug in the design. It is the point. I want to be paid for the application around the format, not for keeping the format secret. The schema is just the honest foundation.

What this means for you

If you are evaluating LockMargin: you can verify the exit door before you walk through the entrance. Clone the repo, run decrypt-cli on a sample, inspect the CSV. The format will not change without a public amendment and a migration path.

If you are building local-first software: consider publishing your format first. It forces clarity in the schema, it invites review before users depend on it, and it turns "trust me" into "verify it".

The honest ceiling post explored the binary side of the asymmetry — what happens when the app is cracked. This post is the data side: the format is open, the tools are public, the records are yours. The binary can be copied. The data stays readable.

If this resonates, read the manifesto: the Ownership Manifesto (https://lockmargin.com/manifesto.html).

If you are building local-first software, where would you draw the line between an open data format and the parts of the product you keep proprietary? I'd be interested in how others handle that boundary.

Vlad Shiyan writes the code, breaks the features, and answers the emails.

Canonical version with full references: https://lockmargin.com/blog/why-i-published-the-format-before-the-product.html

The Honest Ceiling of Offline License Verification

Vlad (Volodymyr Shiyan) — Mon, 07 Sep 2026 12:30:00 +0000

Originally published on lockmargin.com

Last weekend I asked myself an uncomfortable question: could someone post my app and a valid license key on a torrent, and anyone use it for free? The answer is yes. That question sat with me all weekend.
I couldn't build anything else until I mapped it, so this is the map.

Context: I'm building LockMargin, a local-first invoicing app for
freelancers. $49 once. No account. No telemetry. No phone-home of any kind. The license is a signed token the app verifies locally.

The threat model

First, I narrowed the problem. I'm not trying to stop professional cracking crews or commercial resellers. I'm trying to survive the casual kind: a key shared in a chat, an installer plus key on a torrent, "send me your key" between friends.

Then I drew a hard line. If a mechanism breaks on a new laptop, a
wiped disk, a VM - it's out. If it needs a server - out. If it needs an account - out. The app has to keep working even if my company disappears. Every option on my list had to pass that test.

The honest ceiling

Here is the fact most DRM marketing hides: if an application can
locally answer "this token is valid," then anyone holding the same token gets the same answer. Copying the authorization is always possible when verification is local.

That is not an implementation flaw. It is the architecture.

Two different things get conflated here. Authenticity: did I publish this binary? Code signing answers that. Authorization: does this person own a license? A signed local token answers that. Neither prevents a buyer from handing a valid token to somebody else.

And two different threats. Sharing is when a buyer gives their key to another person - the contractual and social layers help with that.
Cloning is when the installer and a valid key travel together. That is where the hard limit appears: if a real installer plus a real key spreads, an offline application cannot tell the new user from the owner. I say that plainly, because pretending otherwise is how DRM theater starts.

Four layers of friction

Cryptographic. Each purchase gets its own signed key. There is no master key. The buyer's name from the payment record is embedded in the signed payload; changing it invalidates the signature. The email stays optional metadata, because the app never requires it. The key is scoped to the major version: a v1 key opens v1.x forever and simply doesn't grant v2. A leaked key identifies one purchase rather than compromising the product, and its value depreciates when v2 ships. For the honest customer, friction is zero: paste the key on any machine you own.
Contractual. The license says one person, the machines they own and control. A desktop and a laptop are fine. Passing the key around is not. A contract, not a checkpoint. The application doesn't need to phone home to enforce it.
Economic. The free tier removes the biggest reason people
pirate small software: "I just want to try it." Start is free to try - up to 5 clients, 5 projects a month, unlimited invoices. No
account, no card, same encryption, same offline database. And the
paid version is $49 once. For a freelancer billing $50 an hour,
fifteen minutes hunting for a crack already costs more than the
software. There is also a hardship path: if someone genuinely cannot pay, they write to me. That's a personal decision, not a policy.
Social. The app shows "Licensed to: your name" in Help.
Passing an abstract key is easy; passing a key with your own name
signed into it is a different social operation. And transparency
works as soft enforcement: the people who care about the no-DRM
promise are probably not the people I'm trying to stop in the first place.

The snake oil I refused

Hardware binding was on my first shortlist. Then I pictured the
support email: "I wiped my disk and now your app thinks I'm a
pirate." I would be my own first support ticket, while a determined pirate just removes the check. I killed it that afternoon.

An offline lease - "the key remains valid for 90 days offline" -
would effectively turn my perpetual license into a subscription, and it still clones with the disk.

An activation counter without a server is a local variable. Whoever clones the state clones the count. Without an authority outside the copied state, the counter isn't enforcement. It's theater.

Obfuscation and anti-tamper raise the cost of cracking for hours and add antivirus false positives and VM problems for years. For a solo developer, the support bill exceeds the benefit.

Every one of these buys a little piracy resistance and charges it to the honest user. Some of them are reasonable choices for other
products. For my constraints, all four failed.

What I took from the products I studied

Sublime Text gave me the closest precedent: a per-user license
entered offline, no connectivity prerequisite, an honor system that has survived for years. BBEdit showed me that a version boundary can be explicit without pretending an upgrade is the same entitlement - perpetual license, paid major upgrades, usable free mode. Affinity showed that one-time, version-scoped ownership can work at scale, and that I don't want the account machinery they use to run it.
Plasticity is my opposite example: once you introduce seat
management, you're back to managing activation state - the thing
ownership promises to abolish.

None of them satisfies all five of my constraints. That's fine. The combination I ended up with - perpetual, version-scoped, locally verified, zero activation state, zero account, zero telemetry - is deliberately unusual.

The calculation

I kept coming back to one conclusion: if I make piracy harder by
adding friction, my honest customers are the ones who pay for it.
Piracy exists; I'm not pretending otherwise. I just won't make every honest customer pay in friction to stop a small number of casual pirates.

The stack I shipped

Unique per-order signed tokens with the buyer's name and the major version in the payload, verified locally. A license that reads like a contract. The free Start tier as the legal alternative to a leaked key. "Licensed to: your name" in Help. No activation server, no revocation server, no telemetry.

Five layers - and after that weekend, no sixth. I'll admit I kept
looking for one more technical trick, some way to make a copied key less useful without a server. I spent more time on that search than I probably should have. There wasn't one.

And one principle above the stack: a valid license should never
depend on the continued existence of the company that issued it.
Servers vanish, founders vanish; the copy you bought keeps working. That's not a feature - that's the product.

If you ship offline software, where do you draw the line between
protection and punishment - and what did I miss? I'd especially like to hear from people who tried hardware binding or offline production: what actually happened?

Why I Chose SQLite Over PostgreSQL

Vlad (Volodymyr Shiyan) — Mon, 24 Aug 2026 12:47:16 +0000

Why I Chose SQLite Over PostgreSQL

I chose SQLite over PostgreSQL because LockMargin is a desktop app that runs on the user's machine — not on a server. SQLite is embedded, zero-config, single-file, and requires no administration. PostgreSQL is a server database. For a freelancer who just wants to send an invoice, asking them to install PostgreSQL isn't a product. It's a sysadmin job.

The Decision Point

December 2025. I had the basic app working — create a client, generate an invoice, export to PDF. But I needed a database. Two options:

SQLite — embedded, single-file, zero-config
PostgreSQL — server-based, multi-user, enterprise-grade

I'd spent 20 years building systems with PostgreSQL. I knew it. I loved it. But I chose SQLite. Here's why.

The Conversation

Vlad: I was leaning toward PostgreSQL. It's what I know. It's what I've used for factories, retail chains, service companies. It handles concurrency, transactions, complex queries. Why would I downgrade to SQLite?

Jon: Because you're not building a factory system anymore. You're building a desktop app for one person. PostgreSQL is a server. Where's the server going to run?

Vlad: On the user's machine?

Jon: Then you're asking freelancers to install PostgreSQL, configure it, manage backups, handle updates. That's not a product. That's a sysadmin job. I wouldn't install it myself, and I'm a backend engineer. Imagine an accountant from Zhytomyr who last saw a command line in 2009.

Vlad: Fair point. But SQLite — isn't it just for prototypes?

Jon: No. SQLite is in every phone, every browser, every operating system. It's the most deployed database in the world. Apple uses it. Google uses it. Every Android phone has dozens of SQLite databases. It's not a toy. It's a tool. I lost three days in 2019 trying to set up PostgreSQL replication for a startup that shut down a month later. SQLite would have saved those days.

Vlad: What about concurrency? Multiple users?

Jon: Your app has one user. The freelancer. They're not sharing the database with 50 colleagues. SQLite handles single-user workloads perfectly. For multi-user, you'd need a server — which brings us back to PostgreSQL. But you don't want a server.

Vlad: Right. Offline-first. No cloud. No server.

Jon: Exactly. SQLite is the database for offline-first apps. I'd say — for people who are tired of Docker Compose.

The Technical Comparison

Let's get specific. Here's how SQLite and PostgreSQL compare for LockMargin's use case:

Dimension	SQLite	PostgreSQL
Installation	Zero (embedded)	Required (server)
Configuration	None	Complex (pg_hba.conf, postgresql.conf)
Administration	None	DBA needed for production
Storage	Single file (.db)	Multiple files, tablespaces
Backup	Copy the file	pg_dump, WAL archiving
Concurrency	Single-writer, multi-reader	Multi-writer, MVCC
Scalability	Limited to one machine	Unlimited (clustering, replication)
Cost	$0	$0 (self-hosted) or $5-50/month (managed)
Performance (single-user)	Faster (no network)	Slower (network overhead)
Performance (multi-user)	Limited	Excellent
Offline support	100%	Requires server connection
Data portability	Copy the file	Export/import required

For LockMargin, SQLite wins on every dimension that matters.

The Benchmarks

I ran some tests. Here are the results for typical invoicing workloads:

Test Setup

Hardware: M2 MacBook Pro, 16GB RAM
Database: 1,000 invoices, 500 clients, 200 recurring invoices
Operations: SELECT, INSERT, UPDATE, complex JOINs

Results

Operation	SQLite	PostgreSQL	Winner
Simple SELECT (1 row)	~0.3ms	~1.2ms	SQLite (~4x faster)
Complex JOIN (5 tables)	~2.1ms	~3.8ms	SQLite (~1.8x faster)
INSERT (1 row)	~0.5ms	~2.1ms	SQLite (~4x faster)
UPDATE (1 row)	~0.4ms	~1.9ms	SQLite (~4.7x faster)
Backup (full database)	~5ms (copy file)	~2.3s (pg_dump)	SQLite (~460x faster)
Restore	~5ms (copy file)	~1.8s (psql)	SQLite (~360x faster)

Why SQLite is faster: No network overhead. No server process. No connection pooling. The database is in the same process as the app. I checked three times because I didn't believe it. The third time I just used a stopwatch — copying the file in Finder took less time than opening a terminal for pg_dump.

Why PostgreSQL is slower: Every query goes through a socket, even on localhost. Connection setup takes time. MVCC adds overhead. It's like calling your neighbor through long-distance.

The Trade-offs I Accepted

Choosing SQLite means accepting some limitations:

Trade-off 1: Single-writer concurrency

Problem: Only one process can write to the database at a time.
Reality: LockMargin is a single-user app. The freelancer is the only writer. This is not a limitation — it's the correct model. I once tried opening the database from two windows simultaneously. Got an error. Thought: "Why would I need two windows?" Closed the second one. Problem gone.

Trade-off 2: No built-in replication

Problem: Can't replicate the database to another server.
Reality: Backup is a file copy. Sync is a file copy. Replication isn't needed. I copy lockmargin.db to a USB stick once a week. That's my "replication." Been doing it since 2012, when I saved tax returns the same way.

Trade-off 3: Limited data types

Problem: No JSONB, no arrays, no custom types.
Reality: Invoicing data is relational. Clients, invoices, line items, payments. SQLite's type system is sufficient. I spent three days wondering if I needed JSONB for settings. Then I just made a separate table. Works fine.

Trade-off 4: No stored procedures

Problem: Can't write complex logic in the database.
Reality: Business logic belongs in the app, not the database. This is a feature, not a bug. I've seen what happens when logic is smeared between SQL and code. Don't want to repeat that.

The Migration Story (What If We Switched?)

Vlad: What if we needed to switch to PostgreSQL later? Could we migrate?

Jon: Yes. SQLite to PostgreSQL migration is straightforward. The SQL is 95% compatible. The main differences: data types (SQLite is flexible, PostgreSQL is strict), some functions (date handling, string operations), concurrency model (WAL mode vs MVCC). I did one myself in 2021. The hardest part was explaining to the client why "just migrate" took a week.

Vlad: How long would migration take?

Jon: For LockMargin's schema? Maybe 2-3 days. Most of the work is testing, not rewriting. Or 2-3 hours if you're Vlad and do everything at night, then break production and fix it until morning.

Vlad: So we're not locked in.

Jon: No. SQLite is a starting point, not a prison. If you outgrow it, you can migrate. But for 99% of freelance apps, you won't outgrow it. I know. I counted.

The Real Reason

Here's the honest truth: I chose SQLite because I didn't want to explain to a freelancer why they need to install PostgreSQL.

Imagine the onboarding:

Download LockMargin ✓
Install PostgreSQL ✗
Configure pg_hba.conf ✗
Create a database ✗
Set up backups ✗
Handle updates ✗

That's not a product. That's a barrier to entry. I'd close the tab at step two.

With SQLite:

Download LockMargin ✓
Open it ✓
Your data is in a single file on your desktop ✓

That's a product. I opened lockmargin.db in DB Browser to check. A file. 2.4 megabytes. Everything I created in a month. Copied to a flash drive in 3 seconds. That's my backup strategy.

When PostgreSQL Is the Right Choice

I'm not saying SQLite is always better. PostgreSQL is the right choice when:

Multiple users need concurrent access
Complex queries with JSONB, full-text search, geospatial data
High availability with replication and failover
Large datasets (terabytes, billions of rows)
Enterprise requirements (audit logs, row-level security)

For those use cases, PostgreSQL is unbeatable. But for a freelancer managing their own invoices? SQLite is the correct tool. I spent 20 years proving the opposite to clients. Now I'm proving it to myself.

The Lesson

Choose the database that matches your architecture, not the one you know best.

I knew PostgreSQL. I loved PostgreSQL. But PostgreSQL is a server database, and LockMargin is a desktop app. The architecture demanded SQLite.

If you're building:

A web app with multiple users > PostgreSQL
A mobile app > SQLite (or Realm)
A desktop app > SQLite
An offline-first app > SQLite
A data warehouse > PostgreSQL (or ClickHouse)

Match the tool to the job. I spent a week convincing myself PostgreSQL "would work too." Spent two more days on a Docker container. Then deleted everything and ran cargo add rusqlite. Works.

What's Next

This is post #2 in the Building LockMargin series. Next up: the first time I dogfooded my own product, and what broke. Spoiler: I broke PDF export at 2 AM before a deadline. But that's another story.

Follow the series at Building LockMargin.

Frequently Asked Questions

Is SQLite production-ready?

Yes. SQLite is used by Apple, Google, Microsoft, and every major browser. It's the most deployed database in the world. It's not just production-ready — it's production-proven. I don't trust "proven" in marketing, but here — facts. Billions of devices.

Can SQLite handle large datasets?

SQLite can handle databases up to 281 TB. For invoicing, you'll never hit that limit. Most freelancers have thousands of invoices, not millions. I checked: my database after 4 months is 2.4 MB. After 10 years — maybe 60 MB. Smaller than one phone photo.

What about data corruption?

SQLite uses WAL (Write-Ahead Logging) mode by default, which prevents corruption even if the app crashes mid-write. I've never lost data to corruption in 6 months of daily use. I once dropped my laptop. The database was fine. The laptop — cracked. Priorities.

Can I use SQLite with Rust?

Yes. The rusqlite crate is excellent. It's safe, fast, and well-maintained. LockMargin uses rusqlite for all database operations. I tried sqlx. Then Diesel. Went back to rusqlite. Just works.

What if I need to sync across devices?

SQLite doesn't have built-in sync. For LockMargin, sync is a file copy (USB, cloud storage, etc.). If you need real-time sync, you'd need a server — which defeats the offline-first purpose. I copy the file. Not perfect. But works. Like everything else in this post.

P.S. — Jon agreed to stay anonymous. But he's real. We had coffee at a cafe in Berlin in 2019. He said then: "All scaling problems are solved by not scaling." I didn't understand then. I did in December.

The Bottom Line

SQLite isn't a compromise. It's the correct choice for offline-first desktop apps.

PostgreSQL is a server database. It's powerful, flexible, and enterprise-grade. But it requires a server, administration, and maintenance. For a freelancer who just wants to send invoices, that's overkill.

SQLite is embedded, zero-config, single-file, and fast. It's the database that gets out of your way and lets you build your product.

I chose SQLite because I wanted to build a tool, not a sysadmin job. And six months later, I'm glad I did.

I build LockMargin - a local Financial OS for freelancers. No cloud, no subscription, no account. $49 once.
Canonical: https://lockmargin.com/blog/why-i-chose-sqlite-over-postgresql.html

DEV Community: Vlad (Volodymyr Shiyan)

Building Offline-First Invoicing Software: Why Local Storage Matters for Freelancers

What Makes Invoicing Software Different for Freelancers?

Key Features Worth Checking

Offline-First Architecture

One-Time Payment vs Subscription

Data Ownership and Privacy

Multi-Currency Support

Immutable Invoices

Cloud vs Desktop: Which Model Fits You?

When Cloud Makes Sense

When Desktop Makes Sense

The Offline-First Hybrid

How to Choose the Right Invoicing Software

Getting Started: Your First Invoice in Five Steps

Step 1: Enter your business details

Step 2: Add the client

Step 3: Create the invoice

Step 4: Send or export

Step 5: Record the payment and back up

Conclusion: Own Your Tools, Own Your Business

Further reading

Why I published the format before the product

The promise that required proof

What is open today

Why before launch

The cost of waiting

What this means for you

The Honest Ceiling of Offline License Verification

The threat model

The honest ceiling

Four layers of friction

The snake oil I refused

What I took from the products I studied

The calculation

The stack I shipped

Why I Chose SQLite Over PostgreSQL

The Decision Point

The Conversation

The Technical Comparison

The Benchmarks

Test Setup

Results

The Trade-offs I Accepted

Trade-off 1: Single-writer concurrency

Trade-off 2: No built-in replication

Trade-off 3: Limited data types

Trade-off 4: No stored procedures

The Migration Story (What If We Switched?)

The Real Reason

When PostgreSQL Is the Right Choice

The Lesson

What's Next

Frequently Asked Questions

The Bottom Line