Data Tables Are Here! 📊

Community Highlights
41

Fabulous update, thank you team!

My 2 cents:
Even though it takes only a smol workflow to import data, a native data import would be a significantly better UX. Now every new data source requires a new workflow, and data table manual creationData tables API endpoints would allow for universal data import agents able creating new data tables. Still, native data import feature seems rather appropriate.

This might be in the backlog, even so: it would be nice to have directories in the data tables.

42

Data Tables are great! However here are some thoughts:

  1. Column header does not accept anything besides English, that means all and any Asian languages would not be allowed . Any plan to add support for UTF 8 character?
  2. Once a type is set , the column would not accept anything besides that type. Like if the column is set to number then no text is allowed to be inserted into that column. It would be nice to have an option to make exception.
  3. It would also be nice to be able to insert data into specific cell of the data table.
43

I’m currently testing the Data Tables feature here. It’s a functionality that opens the door to many new applications in n8n. Thanks to the project team, really cool work!
After running some tests, I’d like to share a few simple suggestions that could help improve implementations where I’m using Data Tables:

  1. Output adjustments: I believe the Data Tables nodes could benefit from more output control options, especially a “transparent” mode where the output matches the input, and inserts or updates to the table happen without disrupting the existing workflow data. A good approach would be something similar to the Edit Fields (Set) node, which has the Include Other Input Fields option. Combining that with a similar option for query results, like selecting Input Fields to Include as All or naming specific fields for output, would be very helpful for implementing process controls and similar use cases.
  2. Accessing Data Tables via Code node programming: This would make it easier to use Data Tables in more advanced scenarios, unlocking an even wider range of applications for this new feature. Apologies if this is already implemented. I couldn’t find anything about it in the documentation.
  3. JSON field type: This would greatly simplify storing data with more flexible structures. I’m already doing this in my tests, but I have to convert JSON → string to store it, and then string → JSON when retrieving it. This adds an extra step to the workflow, which increases the chance of errors.
    Once again, thank you and I hope this feedback contributes something useful!
1 Like
44

Where do we do to report bugs in the new system?

It looks nice but the ‘upsert’ does upsert, it inserts only (the joy of Beta code :-).

For example, given a table with three added cols: domain, header, value if I try to upsert the value for a given domain and header the new values are inserted as add’l rows. The timestamps are updated, but that’s not an upsert. If the database is truly a time-series then there should be a view of ‘current rows’ that allows viewing only one row per series.

{
“nodes”: [
{
“parameters”: {
“operation”: “upsert”,
“dataTableId”: {
“__rl”: true,
“value”: “Gs5dGcKafkPWhGT2”,
“mode”: “list”,
“cachedResultName”: “HTTP Headers”,
“cachedResultUrl”: “/projects/MMVRo9L4qTSnSwAF/datatables/Gs5dGcKafkPWhGT2”
},
“matchType”: “allConditions”,
“filters”: {
“conditions”: [
{
“keyName”: “Domain”,
“keyValue”: “LawRuler”
},
{
“keyName”: “Header”,
“keyValue”: “Authentication”
}
]
},
“columns”: {
“mappingMode”: “defineBelow”,
“value”: {
“Value”: “={{ $json.Authorization }}”,
“Domain”: “LawRuler”,
“Header”: “Authorization”
},
“matchingColumns”: ,
“schema”: [
{
“id”: “Domain”,
“displayName”: “Domain”,
“required”: false,
“defaultMatch”: false,
“display”: true,
“type”: “string”,
“readOnly”: false,
“removed”: false
},
{
“id”: “Header”,
“displayName”: “Header”,
“required”: false,
“defaultMatch”: false,
“display”: true,
“type”: “string”,
“readOnly”: false,
“removed”: false
},
{
“id”: “Value”,
“displayName”: “Value”,
“required”: false,
“defaultMatch”: false,
“display”: true,
“type”: “string”,
“readOnly”: false,
“removed”: false
}
],
“attemptToConvertTypes”: false,
“convertFieldsToString”: false
}
},
“type”: “n8n-nodes-base.dataTable”,
“typeVersion”: 1,
“position”: [
352,
-80
],
“id”: “7f6fea6d-9c56-46da-bafd-2f7a00e01306”,
“name”: “Upsert row(s)”
}
],
“connections”: {},
“pinData”: {},
“meta”: {
“instanceId”: “b63a42e5331cc5aba735306f631ed22e73515e65e5bd3692c0896eace4fcee37”
}
}

45

Hallo everybody.

This is a great feature. I build a converter to Shift your flows with Google Sheets nodes to the new n8n datatables. Just Upload your Flow and get it converted. Straight forward. Best Alf

46

Will this feature stay free for self-hosting?
EDIT: I saw the answer saying it’s free (forever).

Used it a bit, the interface looks nice!
That being said, the IF Exists node is weird.
Shouldn’t that node have an else branch too?

47

It’s an amazing core feature, thank you again n8n team.

my 2 cents after testing: I found it shares the same database as n8n’s main tables, like workflow executions, etc. It is risky for me to use it in production or rely on it for large lists for now. If I were to use it, I would prefer a separate database for it and would prefer if it supported something like SQLite (binary files) or Redis (Dragonfly). We use Redis JSON for faster data processing and large JSON files. Redis is already familiar to n8n users because n8n’s queue uses it as well, so there’s no extra setup here for some users. However, SQLite as a binary file for each table created could also be a better option for future backups and to support all n8n setups.

1 Like
48

Excellent, That’s really a good news @melinda.n8n

49

I am running self-hosted n8n and having problem to update to the current version

50

really awesome feature.

however, to be able to replace other db/table types we really need trigger nodes for add, update, add_or_update. The google sheets integration is very good, if we could get rough feature parity with that it would be awesome.

51

agreed. and not to try to turn this great feature into a full fledged database, but separate files could also enable separate disk locations which is effectively ‘sharding’.

52

Can just someone tell me can we use n8n to scrap the structure as well as non structure data from any web? And then store it in DT?

53

OMG, amazing feature!! Currently, I just see some limitations in the data types - maybe you could add long text (html codes etc.) fields, select fields or lookup fields to other database tables…

54

The ability to store them as binary data could be very helpful to my mind

55

Is it possible to duplicate a data table? I can’t see a way to do so.

56

This is potentially a very useful feature. Many times I have small amounts of semi-static data (what would be constants or configuration in traditional programming). For example, in a complex workflow that notifies different groups of Slack users under different conditions, putting the mapping of department to Slack group into a simple data table would be a fantastic way to turn a bunch of ugly conditionals, hard-coded data, or external fetching into a simple table lookup. And it makes it very easy to keep it updated.

Unfortunately, as it exists right now, there are several limitations that mean I can’t use this feature, and am going to have to figure out how to disable it company-wide so people don’t start using it and run into these problems.

1. No API support. We use the n8n API to back up and manage our environments and integrate with CI/CD workflows. Without being included in the API, data tables become an invisible, unmanageable dependency.

2. No backup. Somewhat as a consequence of the above. I see there is a note in the documentation to build import/export workflows, but requiring everyone to individually build ad-hoc export systems for their data tables and manage ensuring they run and wherever they put them is not a substitute for centralized backup.

3. Git integration? What’s the story for handling data tables between dev and production environments? We unfortunately can’t use the git integration because of its own extreme limitations, so we’ve had to build a workaround through the API (goes back to #1), but even if we could I’m not sure whether the issue of multiple environments was considered at all.

I know this is a beta feature, and I’m providing this feedback in the hope is that the final version will be more integrated with n8n rather than feeling like a partially completed afterthought. I’m really excited to be able to use this.

3 Likes