# Pick the Wrong Database? Switch in One Line

> Same sign-in, same routes, zero rewrites. How one setting switches your app between SQLite, MongoDB and Supabase.

Source: https://boringpush.com/blog/one-switch-database

The most expensive line of code in an early-stage startup is the database migration nobody budgeted for.

You start on a managed cluster. You outgrow the free tier or hit connection limits during a traffic spike. Suddenly you spend a sprint rewriting queries, schemas and pooling logic.

Remove that rewrite before you write your first entity.

One setting decides which database your app uses.

SQLite on your own server.

MongoDB in the cloud.

Or Supabase's managed Postgres.

## What you get

You pick a database today and keep the freedom to change your mind.

The same sign-in, orders, boards and store run on all three. Routes, pages and payment webhooks do not change when the database does.

Start on SQLite with no database bill. Move to a managed database the day one server stops being enough.

Or develop locally on SQLite and run production on something else.

## The three-database comparison

| Capability | SQLite | MongoDB | Supabase (Postgres) |
|---|---|---|---|
| **Best for** | Solo founders, a $5 VPS, zero-bill stacks | Document models, flexible schemas | Relational schemas, the Supabase ecosystem |
| **Monthly cost** | $0, runs on your server's disk | A free tier, then a paid plan | A free tier, then a paid plan |
| **Connections** | None needed, in-process access | A managed connection pool | A pooler is needed |
| **Backups** | A daily snapshot built into the kit | The provider's tools | The provider's tools |
| **Switching away** | One setting and a data move | One setting and a data move | One setting and a data move |

Check each provider's pricing page for current plans. They change.

## Same behavior across all three

Your app code never talks to a database driver directly.

Every route asks for what it needs in plain terms.

Find this user.

Create this board.

List this person's posts.

Each engine answers those same questions in its own way and returns plain data. Never a driver-specific object leaking into the rest of the app.

That consistency makes the switch safe. Routes, sign-in, payment webhooks and pages never learn which database is running.

## Adding or removing an engine

The same design lets you add another engine later. PlanetScale. Cloudflare D1.

You write that engine's answers to the same set of questions and register it once. Everything else stays untouched.

It is a developer task, not a setting. BoringPush does not ship those extra engines. The point is that the work is bounded.

## How changes to the database work

BoringPush makes safe, additive changes only. It adds columns with defaults and never drops data.

On SQLite, new columns are added when the app starts, with loud logging if one fails. On Supabase, the matching tables come from a schema file you run once.

Production changes are never run by an agent. A person runs them deliberately, after a staging run first.

## A switching checklist

When the day comes, work through it in order.

- Create the schema on the new engine.
- Copy the rows across and compare counts for users, orders and content.
- Change the database setting on staging.
- Run sign-in, checkout, a board post and the dashboard.
- Change the setting in production and watch the logs.

Keep the old database untouched until you are sure. A rollback is one setting away only while the old data still exists.

## Know this first

Pricing for MongoDB and Supabase changes. Check their pages. Switching engines moves code, not data.

You still move the rows.

## Why BoringPush is the way to do this

Pick wrong? Switch.

One setting chooses SQLite, MongoDB or Supabase. Sign-in, orders and webhooks work the same on all three.

The cost of changing your mind drops to a checklist.

## FAQ

### How do changes work when switching engines?

The data does not move on its own. Create the schema on the new engine, move your rows, change the setting and redeploy.

A brand-new app starts empty, so this is often a non-step. Test on staging before you move real customers.

### Can I run SQLite locally and Supabase in production?

Yes. It is a common workflow: SQLite on your laptop for instant boot without an internet connection, and a managed database in production. Run your main flows on staging against the production engine before you launch, because behavior can differ at the edges.

### Does SQLite handle production traffic?

For most early SaaS products, yes. With write-ahead logging, readers do not block writers, and the kit takes daily snapshots.

BoringPush does not publish a throughput benchmark, so measure your own workload. When a single server stops being enough, that is the moment to move.

### What stays the same whichever database I pick?

Your sign-in, your paid-access checks and your payment webhooks. Analytics also stay in their own SQLite file whichever main database you choose, which keeps busy pageview writes away from payments.

### Which should I start with?

SQLite, unless you have a clear reason not to. It costs nothing, it is fast and it keeps everything on one server you control.

Pick Supabase when you want managed Postgres and plan to run more than one app server. Pick MongoDB if your team already runs it or your data is document-shaped.

## Keep reading

- [One Codebase, Three Databases: SQLite, Supabase, MongoDB](/blog/one-codebase-three-databases-sqlite-supabase-mongodb) — the same idea, step by step
- [Switch Databases With One Line (Zero Rewrites)](/blog/one-switch-database-sqlite-supabase) — the switch in practice
- [SQLite vs Mongo vs Supabase: 2 Triggers End the Debate](/blog/sqlite-vs-mongodb-vs-supabase-nextjs) — when each engine wins