Skip to main content
While SQLite is a popular option for development and lightweight applications, it is not supported in Laravel Cloud production environments. This is because Laravel Cloud environments are ephemeral, meaning the filesystem resets across deployments, reboots, and infrastructure migrations. Since SQLite stores data in a single file on disk (often *.sqlite, *.db, or a path you configure in DB_DATABASE), any changes are lost whenever your application is redeployed, hibernates and wakes, or is moved between hosts.
We recommend Laravel Serverless Postgres for most apps: it auto-hibernates when idle, scales with usage, and keeps persistent storage across deployments. Laravel MySQL is available if you prefer it (Laravel MySQL does not currently support hibernation).

​
Migrating from SQLite to PostgreSQL or MySQL

When you deploy to Laravel Cloud, you need a hosted database such as Laravel Serverless Postgres (Neon) or Laravel MySQL. If your app currently uses SQLite, migrate your schema and data using one of the paths below.

​
SQLite to PostgreSQL (Neon)

1

Export your SQLite data

If you plan to load the .db file with pgloader in the import step below, skip this step and the cleanup step. Otherwise, from your project directory, dump the database to SQL:
sqlite3 your_database.db .dump > dump.sql
2

Clean up the dump

PostgreSQL uses different syntax than SQLite. You only need this step if you import with psql using a hand-edited dump.sql (if you use pgloader with the .db file directly, skip this step). Edit dump.sql as needed:
  • Remove or replace BEGIN TRANSACTION and COMMIT.
  • Replace INTEGER PRIMARY KEY AUTOINCREMENT with SERIAL PRIMARY KEY or BIGSERIAL PRIMARY KEY.
  • Replace BLOB with BYTEA.
  • Remove all PRAGMA statements.
  • Replace TEXT columns that store dates with TIMESTAMP if you want PostgreSQL-native date handling.
  • Strip any OWNER TO or GRANT statements that reference system roles; Neon does not support superuser operations.
3

Import with pgloader or psql

pgloader can load a SQLite file directly into Postgres. Check pgloader’s release notes for PostgreSQL 18 compatibility before you proceed. If it supports your target version, run (substitute the full path to your SQLite file; see pgloader’s SQLite reference for URI forms):
pgloader sqlite:///absolute/path/to/your_database.db "postgresql://user:[email protected]/dbname?sslmode=require"
sslmode=require is mandatory for Neon.If pgloader does not yet support PostgreSQL 18, finish cleaning dump.sql manually and import with psql:
psql "postgresql://user:[email protected]/dbname?sslmode=require" < dump.sql
4

Verify the migration

Confirm that row counts match across all tables, foreign keys and unique constraints behave as expected, and your application runs against the new database without query errors.

​
SQLite to MySQL 8.4

1

Export your SQLite data

sqlite3 your_database.db .dump > dump.sql
2

Clean up the dump

Edit dump.sql for MySQL compatibility:
  • Translate SQLite’s INTEGER PRIMARY KEY AUTOINCREMENT pattern into a MySQL integer primary key column that uses AUTO_INCREMENT.
  • Replace TEXT with LONGTEXT or VARCHAR(n) as appropriate for your columns.
  • Remove all PRAGMA statements.
  • Change double-quoted identifiers (for example, "column") to backticks (for example, `column`).
  • Replace BEGIN TRANSACTION with START TRANSACTION.
  • Keep BLOB as BLOB.
  • Booleans: SQLite stores booleans as 0/1 integers; MySQL’s TINYINT(1) behaves the same way.
  • utf8mb4 is the default character set for new databases on MySQL 8.4 in most configurations, so you often do not need to set it explicitly.
3

Import into MySQL

mysql -u user -p target_db < dump.sql
4

Verify the migration

Confirm that row counts match across all tables, foreign keys and unique constraints behave as expected, and your application runs against the new database without query errors.

​
Before you go live

  • Run through the migration on a staging environment first.
  • For MySQL, the sqlite3-to-mysql package (pip install sqlite3-to-mysql) can automate dialect conversion instead of editing dump.sql by hand.
  • SQLite is permissive about types; PostgreSQL and MySQL are stricter, so invalid data may only surface after you migrate.
  • Foreign keys are not always enforced in SQLite (for example, when PRAGMA foreign_keys is off). Your target database will enforce them, which can reveal existing data integrity problems.