Forum Academy Marketplace Showcase Pricing Features

How do you plan your database structure? (Tools)

Hello bubble lovers :heartbeat:,

a simple question for all of you:

How do you plan a database structure, especially for large projects?
Do you use pen and paper, a planning tool (like or chisel in stone?

Tell me and the bubble community!

:arrow_forward: I for myself use, but I am not quite happy with it. It is too inconvenient adding a lot of elements in a short time.

I’m one of those digital heads that always, no matter what my goal, thinks that “there’s an app for that.” I scoffed at those who brought notebooks to meetings, etc,. That’s why it took me years to realize that there’s simply no digital tool that can replace the flexibility of pen and paper. There’s just something about that freedom that’s a lot more efficient for me.

I’ve learned the hard way to take the planning seriously, and living by my Bubble mantra: creating is fast, changing is a bitch (ok, I just made that up, but it’s true).

What digital tools can help you with though, is collaboration. So if I’m presenting to a client, I mostly use Powerpoint/equivalents or LucidChart if it’s more complex. Whenever I’m bringing in more people to a project, I turn to a project management tool.

I am finding the planning documentation by the AirDev team extremely useful.

Thanks @vlad for letting us see how you guys work!

Example of Building Uber

Check out the documentation for their templates and best practices:

Thanks for the shoutout @dserber, glad you’re finding our stuff useful!

And @dev2 - here’s our guide to database planning, we usually use an Excel spreadsheet :slight_smile: :

1 Like

I typically use a tool like and entity relationship models, but I’ve got some history as a developer working heavily on RDMS (SQL Server, PostgreSQL, MySQL) and old habits die hard.

That said, I still like the approach. While it’s rare that what’s planned is exactly what goes into product, thinking about structure, architecture, etc. can help expose potential pain points early on.

@petter is right - change is more painful than creating.