Deploying a Local SQLite App to Vercel: The Trap Nobody Tells You About

SQLite is almost perfect for a small local application. There is no database server to configure, the whole database can live in one file and development is incredibly simple.

Then you deploy the app to Vercel.

The application may still build successfully, the database file may even exist during deployment, and everything can look fine at first. The problem is that a serverless environment is not the same thing as my laptop.

On my computer, the SQLite file stays there. I write to it today and the data is still there tomorrow.

In a serverless deployment, the filesystem should generally be treated as temporary. A function can run on one instance, another request can run somewhere else, and the files created during execution are not a reliable place for persistent application data.

That means this architecture:

Next.js app → local SQLite file

works very nicely in development but becomes a bad assumption once the application is distributed across serverless infrastructure.

The solution is not necessarily to abandon SQLite itself. There are hosted databases built around SQLite-style workflows, and there are plenty of other managed database options. The important thing is that persistent data needs to live in persistent infrastructure.

This is one of those deployment problems that has almost nothing to do with the code being “wrong”. The code is perfectly reasonable for the environment in which it was written.

The environment changed.

That is why I now try to think about persistence before deployment rather than only after the first production error. If a piece of data must survive requests, deployments and restarts, I should know exactly where that persistence comes from.

A local database file is persistence on my laptop.

It is not automatically persistence in the cloud.