When Not to Use SQLite

SQLite is easy to underestimate.

It is not a toy database. It is an embedded SQL engine designed around a very different architecture from PostgreSQL, MySQL or SQL Server.

That difference is exactly why SQLite can be brilliant in one application and a bad fit in another.

SQLite’s own documentation describes its focus as local application/device storage, while client/server databases emphasize centralization, concurrency and shared enterprise data.

1. Many computers need direct database access

SQLite is embedded into the application.

There is not a SQLite database server accepting connections over TCP in the normal PostgreSQL/MySQL sense.

Usually that is a strength:

Application
   ->
SQLite library
   ->
database.db

No database daemon.

No separate authentication layer.

No network round trip.

But if 30 application servers all need to directly open the same database file over a network filesystem, the architecture starts working against SQLite.

SQLite’s own guidance recommends a client/server database when many clients need to access the same database directly across a network, partly because network latency and filesystem locking behavior become concerns.

2. You need heavy concurrent writing

This is probably the most important limitation to understand.

SQLite supports many concurrent readers, but only one writer at a time per database file.

That sounds worse than it often is.

A write transaction can be extremely short, so many applications happily queue writes and never notice.

But imagine:

hundreds of workers
        ->
constant writes
        ->
same SQLite database

Eventually serialization becomes part of your performance model.

SQLite’s documentation explicitly recommends considering a client/server database when many writers need to modify the database simultaneously and cannot simply take turns.

If your workload is mostly reads with occasional writes, SQLite may be fantastic.

If your business is basically a write-concurrency benchmark, choose something else.

3. You need horizontal database scaling

One appealing thing about PostgreSQL or other server databases is that the database has its own operational identity.

You can introduce:

replicas
failover
connection pooling
managed backups
database monitoring
independent scaling

SQLite is a file accessed by your application.

There are architectures and external systems that replicate SQLite or build distributed systems around it, but that is no longer the simple SQLite model.

If your design requirement starts with:

We need a multi-node database cluster across regions…

SQLite probably is not the default answer.

4. The database is shared organizational infrastructure

SQLite works wonderfully when the database belongs to an application.

For example:

desktop_app -> local.db
mobile_app -> local.db
CLI_tool -> local.db
small_server -> app.db

But imagine a company database used by:

billing
CRM
analytics
support
admin portal
reporting
warehouse jobs
external integrations

Now central access control, connection management, auditing, independent backups and operational tooling become increasingly important.

That is the environment client/server database systems were designed for.

5. You are scared of using SQLite on a website for the wrong reason

There is also an opposite mistake worth correcting.

Do not reject SQLite merely because:

It is just a file.

SQLite’s documentation explicitly lists server-side databases and websites among valid uses, and notes that a server application can serialize database access itself.

A small content site, admin system, internal application or moderate web application can work perfectly well with SQLite.

The relevant question is not:

Is this a website?

It is:

What are the concurrency, deployment and availability requirements?

6. The database must survive independently of an ephemeral server

Suppose your deployment platform regularly destroys and recreates application instances.

If the SQLite file lives only on that ephemeral filesystem:

container destroyed
        ->
database destroyed

That is not SQLite’s fault.

It is an architectural mismatch.

You need persistent storage, backups, replication, or an external database.

For a single persistent VM this can be wonderfully simple.

For a fleet of disposable stateless application instances, a centralized database service may fit much more naturally.

When SQLite IS a Great Choice

SQLite is difficult to beat for:

• mobile applications
• desktop software
• embedded devices
• command-line tools
• local caches
• application file formats
• testing
• prototypes
• small server applications
• low-write-concurrency web applications
• systems where having no database server is an advantage

The official project specifically highlights embedded/device storage, application files, local caches, server-side use and internal databases as appropriate scenarios.

SQLite vs Alternatives

Requirement	SQLite	PostgreSQL	Redis
Zero administration	Excellent	Moderate	Moderate
Local application storage	Excellent	Poor fit	Poor fit
SQL / relational queries	Excellent	Excellent	Poor
Many concurrent writers	Limited	Excellent	Excellent
Multi-server centralized DB	Poor fit	Excellent	Good for specific roles
Embedded application	Excellent	Poor fit	Poor fit
Independent DB scaling	Limited	Excellent	Excellent

Should You Use SQLite?

SQLite is an excellent candidate if:

• the application and database live together
• write concurrency is modest
• you want SQL without operating a database server
• simplicity is a real product requirement
• a single database file is actually an advantage

Think twice if:

• many servers need to write the same database concurrently
• you are putting the file on shared network storage
• database failover must occur independently of application failover
• the database is shared by many unrelated systems
• horizontal database scaling is a near-term requirement

SQLite is often not the database you use until you grow up.

For many applications, SQLite is the database you use because you have realized you do not need anything more complicated.

Sources / Further Reading

• Appropriate Uses For SQLite