> ## Documentation Index
> Fetch the complete documentation index at: https://cloud.laravel.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# SQLite Support

> Learn why SQLite is not supported on Laravel Cloud, which databases we recommend, and how to migrate from SQLite to PostgreSQL or MySQL.

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](../environments#filesystem), 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, sleeps and wakes, or is moved between hosts.

<Tip>
  We recommend [**Laravel Serverless Postgres**](/resources/databases/postgres) or [**Laravel MySQL**](/resources/databases/laravel-mysql): both scale to zero when idle, scale with usage, and keep persistent storage across deployments.
</Tip>

## Migrating from SQLite to PostgreSQL or MySQL

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

### SQLite to PostgreSQL (Neon)

<Steps>
  <Step title="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:

    ```bash theme={null}
    sqlite3 your_database.db .dump > dump.sql
    ```
  </Step>

  <Step title="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.
  </Step>

  <Step title="Import with pgloader or psql">
    [**pgloader**](https://pgloader.io/) 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](https://pgloader.readthedocs.io/en/latest/ref/sqlite.html) for URI forms):

    ```bash theme={null}
    pgloader sqlite:///absolute/path/to/your_database.db "postgresql://user:password@ep-xxx.region.aws.neon.tech/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`:

    ```bash theme={null}
    psql "postgresql://user:password@ep-xxx.region.aws.neon.tech/dbname?sslmode=require" < dump.sql
    ```
  </Step>

  <Step title="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.
  </Step>
</Steps>

### SQLite to MySQL 8.4

<Steps>
  <Step title="Export your SQLite data">
    ```bash theme={null}
    sqlite3 your_database.db .dump > dump.sql
    ```
  </Step>

  <Step title="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.
  </Step>

  <Step title="Import into MySQL">
    ```bash theme={null}
    mysql -u user -p target_db < dump.sql
    ```
  </Step>

  <Step title="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.
  </Step>
</Steps>

### Before you go live

* Run through the migration on a **staging** environment first.
* For MySQL, the [`sqlite3-to-mysql`](https://pypi.org/project/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.