Data in and out

A database is as large as the platform allows — ten gigabytes, rows in the millions — and nothing in PerSQL caps it below that. Every byte that moves is a job: it runs in the background, in chunks, and you watch its progress by polling it (the console shows a bar, the CLI a line). A job is queued, running, then done or failed with a sentence.

Import

A file is uploaded in parts of 16 MiB (the upload routes, or persql import), then an import job reads it back in ranges of 16 MiB, so a file of gigabytes never sits in memory. The formats:

• CSV and TSV — the first row names the columns; types are inferred from the first thousand rows (integer, real, text). One table per file, named after the file.
• Excel — the first sheet, as a CSV would be.
• A SQL dump — run as written, so it can carry many tables. PerSQL’s own exports and backups are dumps.
• A SQLite file — every table copied in.
• A zip — each file inside handled as above.

The job’s result names each table made with its row count, and each file skipped with the reason.

Export

An export walks the table by rowid and uploads parts of 16 MiB, so it too is any size. sql is the whole database as a dump; csv is one table. sqlite writes a real SQLite file, which is done in memory and so is bounded by 64 MiB — a larger database leaves as SQL, which is the same data, and sqlite3 new.db < export.sql makes the file.

Backups

Two kinds, and the list says which:

• A bookmark is taken automatically before the assistant applies a change that is hard to undo. It is SQLite’s own point-in-time mark — no bytes copied, instant at any size — and it can be restored for 30 days.
• A dump is a SQL file you take yourself (POST /snapshots, persql backup, the console’s Backups). It downloads, it restores, and it outlives thirty days.

A restore takes a backup of now first, so a restore can be undone.