Save Claude answers as a clean PDF

## SQLite or PostgreSQL for a side project?

Short answer: **start with SQLite** unless you already know you'll need many concurrent writers or features that only PostgreSQL offers. Here's how they compare for a typical small web app.

### Comparison

| | SQLite | PostgreSQL |
| --- | --- | --- |
| Setup | A single file, no server | Needs a running server |
| Concurrent writes | One writer at a time | Many writers |
| Hosting cost | Free with your app | Separate instance or managed plan |
| JSON support | `json_extract()` and friends | Native `jsonb` with indexes |
| Best for | Prototypes, single-server apps | Multi-service, write-heavy apps |

### When SQLite is enough

- Most requests are reads
- Your app runs on one server
- You want backups to be a file copy

### A quick start

```python
import sqlite3

conn = sqlite3.connect("app.db")
conn.execute("PRAGMA journal_mode=WAL")  # better read/write concurrency
conn.execute(
    "CREATE TABLE IF NOT EXISTS notes (id INTEGER PRIMARY KEY, body TEXT NOT NULL)"
)
conn.commit()
```

> [!TIP]
> Turning on WAL mode lets readers keep working while a write is in progress — it removes most of the "database is locked" errors people hit early on.

### Planning for a later move

If you might switch later, keep the move cheap:

1. Use an ORM or query builder that supports both databases.
2. Avoid SQLite-only quirks such as loose column types.
3. Write migrations as plain SQL files you can replay.

A rough rule of thumb for write capacity, where $w$ is writes per second and $t$ is the average write time in seconds:

$$
\text{utilisation} = w \times t
$$

If utilisation regularly approaches $1$, it's time to move to PostgreSQL.