Hi Dheeraj, welcome to Tadabase.
To help you better, it would be useful to know what type of application you are trying to build. If you can share the main modules or entities in your app, people here can suggest table structures that work well within Tadabase.
In the meantime, here are a few practical start-up tips that I have found useful. Everyone structures things a little differently, so these are simply approaches that have worked well for me.
- Using connections and record IDs
Tadabase provides a connection field type that enables you to easily obtain relational information from other tables.
One thing you may find helpful (when you need to reference an individual record programmatically) is to create a text field named RID (Record ID). Tadabase automatically creates a RecordID for every record, but that field is not always easily accessible via pipes and some other processes.
This gives you a reliable way to reference records when working with pipes and other automations. Create a record rule that copies the system RecordID value into the RID field. Like this:

If this all sounds confusing, DM me and I will show you what I’m trying to explain.
- Be mindful of pipe limits
Depending on the plan you are on, there is a limit to how many pipes you can create.
When you begin exploring pipes, it helps to name them clearly so you can distinguish between pipes that are actively used in your app and ones that you created while experimenting. This makes it easier to remove unused pipes later if you need to free up space.
- Organising tables
As your app grows, organising tables becomes important.
One approach is to group related tables with a naming convention and shared icons. This makes it much easier to visually identify related tables in the builder.
Note: you can reorder tables, but the order sometimes only ‘sticks’ properly after returning to the Tadabase app list and then reopening your app straight after you have moved a table in the table list.
- Design with record pages in mind
Another Tadabase-specific tip is to think about how your record pages will look when designing your tables.
Many Tadabase apps work best with a clear parent to child structure, because record pages are designed to show a main record with related components underneath it.
For example: Customer
This structure allows you to build record pages that show the main record at the top and related tables underneath it, which keeps the app easier to maintain as it grows.
- Documentation and community
If you have not already done so, the Tadabase documentation is very helpful:
https://docs.tadabase.io/
Between the documentation and this community forum, there is a lot of useful information available.
- In my database I need to know when and who created and modified a record. To do that I created 4 fields ‘EnteredBy, (a Connection field to Users), ‘EnteredOn’ (DateTime). These are both updated by a ‘Created’ record rule (or page rule if you prefer). ‘UpdatedBy’ (Text) & ‘UpdatedOn’ (DateTime) are updated by an ‘Edited’ record rule.

If you’re able to share a bit more detail, people here can give much more targeted suggestions. For example: Is the app intended for a single client or multiple clients? What are the main modules or entities you expect to build (for example Customers, Jobs, Projects, Orders, etc.)? What is the main workflow you expect users to follow in the app?
Happy Tadabasing
Colin