One Codebase, Three Databases: SQLite, Supabase, MongoDB

Picking a database is the first decision that can quietly cost you a month.

Pick hosted Postgres on day one and you pay before anyone pays you. Pick SQLite and you worry about the day one server stops being enough.

You don't have to bet. BoringPush runs one codebase on SQLite, Supabase or MongoDB, and one setting moves you between them.

Start on the database that costs nothing

For a new product, SQLite on the same server as your app is hard to beat.

There is no network hop between the app and the database. There is no second service to keep alive. There is no monthly bill.

Backups, write-ahead logging and nightly cleanup are already set up. Most apps grow for a long time before one well-run server becomes the limit.

So the kit starts there, and the end-to-end tests run there on every change.

One front door, three engines

Your app never talks to a database directly.

Every route calls the same small set of functions: create a user, find an order, list a board's posts, set a post's status. They all live behind one front door.

Each database has its own version of those functions, with the same names and the same field names. SQLite has one, Supabase has one, MongoDB has one.

One setting chooses the version that runs. The route that lists posts doesn't know or care which database answered.

What a switch to Supabase takes

Your app code stays the same. Four steps don't happen by themselves.

1. Create the schema once. Run the kit's schema in your Supabase project.
2. Set three values: the database choice, your project URL and your service key.
3. Move your data, if you have any. Rows don't copy between databases on their own. A brand-new app starts empty, so this is often a non-step.
4. Redeploy, then click through your main flows once.

MongoDB works the same way, with a connection string instead of the Supabase keys.

Test a switch before customers

Switch a staging copy first. Sign up, place a test order, post on a board and open the dashboard.

If those four flows work, the main paths work.

Keep your SQLite file as a fallback until you trust the new setup. A fallback you never needed costs nothing. One you needed and lacked costs a weekend.

Which one should you pick?

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

Pick Supabase when you want managed Postgres, a dashboard and more than one app server. It's the natural next step when a single box stops being enough.

Pick MongoDB if your team already runs it, or your data is genuinely document-shaped and changes shape often. If neither is true, you probably don't need it.

Why this matters when an AI writes the code

When an agent adds a feature, the worst outcome is code that works on your laptop and breaks in production.

Because every database speaks the same function names, the agent follows one path: add the data, add the function for each database you use, add a short route. It never invents database-specific code in the middle of your app.

That is the whole trick. Boring, predictable, easy to check.

Know this first

• SQLite is the engine tested end to end. After a switch, run your own smoke test.
• Data does not move by itself. Export it and import it.
• Analytics stays in its own small file next to your app, whichever main database you pick. That is on purpose: it is fast, private and free.
• Features you add later follow the setup you chose. Moving to a database you didn't pick means asking your AI to add that version first.
• One database lives on one server, so you scale up, not out.
• You can decide later, once the product tells you what it needs.

Why BoringPush is the way to do this

Starting on a hosted database means starting with someone else's limits. Starting on SQLite means starting with none, and keeping a way up.

BoringPush gives you both: a database that is free and always on today, and one setting that moves you to Supabase or MongoDB later.

Your app code does not change. Your field names do not change. Your agent follows the same rules on every engine.

Start simple. Grow without a rewrite.

FAQ

Can I start on SQLite and move to Supabase later?

Yes. Your app code stays the same. You run the schema once in Supabase, set three values, move any existing data, and redeploy.

Does switching copy my data?

No. Data doesn't move between databases automatically. New apps start empty, so there's usually nothing to move; if you have data, export it and import it into the new database.

Is SQLite really fine in production?

For most new products, yes. It runs on the same server as your app with no network hop, and BoringPush sets up write-ahead logging, backups and nightly maintenance for you.

Does MongoDB support everything SQLite does?

Every data function that ships in the kit has a MongoDB version with the same field names. Features you add later need their MongoDB version written too, which your AI does by following the project rules.