Are non-WAL tables really 'legacy'?

[peeterburger]

In some of our projects, we make use of non-WAL tables. These are either tables without a designated timestamp or tables for which we require updates. In these cases, WAL is either not applicable or does not make sense.

Is there any incentive to remove non-WAL tables in the future? If not, I think they should not be considered legacy.

[bluestreak01]

hi Peter, do you use questdb standalone or embedded? Also it would be great to understand the business case for your use of non-WAL table. May be there is an example?

[peeterburger]

We use QuestDB standalone.

Use Case 1: We have a table that holds common <key, value> pairs, where the keys are not designated timestamps. In queries, we use this table to extend base tables with additional information through joins. The content of the common table changes frequently over time.

Use Case 2: We update a table based on the existence of entries in another table. In that case, we require a JOIN in the UPDATE query, which is not possible with WAL. However, if there is a workaround for this, it might be less of a problem.

In general, import performance for us is not a concern, as we mostly do batch inserts about once per month. So, besides better resilience, I guess we do not really profit from WAL.

[tris0laris]

Hello Peeter, Thanks for checking in. Since you can perform UPDATE on WAL tables, can you tell us what issue you're facing there?