Multi-table queries and joins

Many non-trivial apps will require some sort of joining data from multiple tables. Right now, Tulip supports linked users have to rely on workarounds to get use-cases implemented. This hinders the creation of more sophisticated use-cases because scaling with workarounds is very difficult.

Simple scenario:

  • One Tulip Table with Equipment Master Data
  • One Tulip Table with Equipment Logbooks


  • If I want to filter Logbook data for some Equipment attribute, I have to copy the data to the Logbook. I have to keep the data then also up-to-date in case Equipment master data is updated later.

  • If I want to show Equipment’s which have pending logbooks, I have to manually track the status in a Equipment Table column. I can’t just query it. Workarounds like doing a loop is not scalable because Tulip also does not have a native looping (this is another major gap) functionality.

  • Performance impact: Because I have to copy data, perform workarounds, the user-experience degrades.

I am proposing to allow table queries to fetch data across multiple tulip tables. I see many user suggestions which are easy to solve when a native table join / query functionality is available.

Hi Jas,

Thanks for bringing this up, just so I make sure I am understanding, linked records does not help here because you cannot query linked columns - that is what is causing you to have to make workarounds?



Right now, you cannot query data from more than one table in Tulip.

Here are some examples for functionalities that is not available:

Table “Logbook”

  • ID
  • Logbook Name
  • Linked Record Equipment

Table “Equipments”

  • ID
  • Equipment Name
  • Equipment Status
  • Linked Record Logbook

Here is a simple tulip table query:
“Show all logbooks for equipments that have status >clean<”

Here is a simple example in the Table widget:
“Filter and display Logbook entries by equipments with status >clean<”

I’m not sure, if I got you right.

There might not be one built in function for querying across tables.
But you can get a list of Equipments by status (Aggregation) and use this as a Filter for the Logbook Table.

I think the overall issue is just limitations with the table design - I can see why it’s written the way it is for simplicity and validation, but having some basic querying language to be able to join, compare and calculate data between tables would sometimes make your life so much easier.

Unfortunately I’m too used to working with SQL and so crave a nice easy way to manipulate that data within an app…

@MarkStuttard @jas Thanks for reaching out about this!

There is not yet a way to query data from multiple tables at the same time (i.e. joining data). So at the moment, the approach that @thorsten.langner has described is the way to go, which allows to solve quite a few use cases.

But we are aware that there are others that can be challenging to build or are not possible at all. Our analytics team is thinking about this topic quite a lot in the context of the overall changes we are implementing (see the Universal Template) and will be implementing in the future. To be transparent, getting to the topic of joining data will still take some time given other steps we need to complete beforehand.

But if you’d be up for it, I’d be very happy to hop on a call with you and learn about what exactly you’d be looking for. If that sounds good to you, please reach out at stefan[at]

Looking forward to hearing from you!


Hi @thorsten.langner, I am aware of this workaround. However, think about it: You have to first run an aggregation, then filter using an “in” on the table widget. For the simplest app/table, this kinda works but think about the UX (table reloads after filter is applied), aggregation limits (1000 entries), performance, more than 2 tables, etc.

@stefan, I want to be clear, this is not only a display limitation. It also has on impact on table design. If possible, I would like to normalize my tables to make the apps more performant and reduce trigger complexity. I have raised this a few times with Tulip team. The usual answer I get is that there is no strong demand for this feature - hence I created this proposal in the community for voting.

I would probably test filtering in another query, not in a widget…

However… you are totally right that this is a workaround, and that the 1000 records limit is a big issue here…

@jas Thanks for reaching out again. We are aware that the ability to query data from multiple sources will allow for additional approaches to table design which in turn will allow for other approaches to app design.

Happy to talk to you about more details and to understand your concrete challenges better. Reach out via email (stefan[at] any time.