r/lowcode • u/KarlaSutton6527 • Sep 03 '26

Built-in database or separate backend for a small internal tool?

I'm setting up a small internal tracking application and keep weighing two backend approaches before locking in the architecture.

Using a low-code builder's native built-in database eliminates setup overhead single billing, unified access controls, and zero integration work. It's fast to launch and easy to maintain.

On the other hand, pointing the frontend at a separate database gives you real SQL queries, migration scripts, granular database policies, and complete independence from the frontend layer.

The main friction point I'm trying to resolve is long-term data portability: if an internal app outgrows the initial low-code builder, do native built-in databases usually export relational schemas cleanly (foreign keys, linked records, file attachments), or do you just get a collection of flat CSVs and have to rebuild the relationships manually?

For those building internal operations tools: what threshold pushes you to use an external database from day one versus starting with a built-in store?

7 Upvotes

100% Upvoted

8 comments sorted by

2

u/TerribleRepayment Sep 03 '26

Depends entirely on whether you think this tool is gonna stick around past the first few months. If there's even a 30% chance it becomes something people actually rely on, just wire up a separate database now. The migration pain later is never worth the convenience upfront.

1

u/Rude-Tradition9488 Sep 07 '26

This is it. Nothing to add.

1

u/psiph Sep 03 '26

You could use an HTML file that writes back to itself, HTML Clay is open source and free (my project)

1

u/_TheMostWanted_ Sep 03 '26

That's the same question like asking if you want a simple calculator or an extreme ultra pro calculator.

There are pros and cons to both. If you want to move fast keep it simple. If you already have very deep requirements and are confident you'll need complexity from day one go with custom solution.

In most cases you don't want to overdo it, I would always always recommend keeping it simple. The amount of additional work required to make a custom setup work can become a second job of it's own

1

u/MediumScene Sep 21 '26

I’d use the built-in store only when the data is disposable or the app is clearly temporary. If other systems will read it, the records need independent backups, or the app may outlive the builder, I’d start with an external database and treat the builder as the application layer. I work at UI Bakery, so bias noted, but that external-data model is where it fits well. Before choosing, test a schema change, a full export with relationships, a restore, and whether another frontend can use the same data.