Release Notes - Datadios v1.11.0
Release Date: 2026-09-10 Release Type: Minor Released By: DataDios Team
⚠️ Breaking Changes
Lineage is now one graph per tenant, and the per-data-source sync endpoints are gone
Lineage used to be built and torn down one data source at a time. It is now built as a single graph covering every data source in your tenant, which is what the lineage screens read as of this release.
The endpoints that drove the old per-data-source path have been removed:
POST /data-lineage/sync/<ds_name>DELETE /data-lineage/sync/<ds_name>GET /data-lineage/sync/<ds_name>/status
If you call these from a script or an orchestration job, remove those calls — these endpoints no longer exist and the response you get instead depends on how your deployment serves the UI. Nothing replaces them per data source; lineage is maintained for the whole tenant. No action is needed if you only use lineage through the product.
What's New
🚀 New Features
Data Quality dashboards that follow what you are looking at
The Data Quality area now answers the question you actually asked. The same charts appear at every level — everything you own, one quality hub, one object — and each is now scoped to the level you are on rather than always reporting across your whole estate. The per-object page in particular used to draw a chart labelled for that object while showing the numbers for its entire hub; it now shows the object.
Fleet-wide numbers are unchanged.
Available in the new UI only.
See which queries touched an object
Every object in the Data Explorer gets a Queries tab listing the workload queries that read or wrote it, taken from the query history the platform already collects from your source.
Key Capabilities:
- A Queries tab per object, paged so a busy table stays usable
- Those same queries drawn as their own node kind in the object's lineage graph
- Stored procedures rendered as nodes in the dependency graph, with query-to-procedure links extracted from SQL Server
Available in the new UI only.
Browse a connection by object type
The catalog rail groups a node's children by what they are — tables, views, procedures, functions, collections, files — with a count against each type, so a schema holding thousands of objects can be narrowed in one click instead of scrolled. This works on every connector with no per-connector setup.
Available in the new UI only.
Domain, environment, classification and tags on Data Explorer rows
Data Explorer rows now carry the governance attributes from the entity catalog — Domain, Env, Classification and Tags — so you can see how an object is classified without leaving the browse view.
Available in the new UI only.
Groups as a platform entity type
Groups join data sources, objects, columns and users as a first-class entity type in the catalog, so group membership is modelled and browsed alongside the rest of your estate rather than held only in the UI.
Available in the new UI only.
A review queue for missing entities
Lineage now has a tab listing the entities it expected but could not find, so a gap in a graph is something you can work through rather than something you have to notice.
Available in the new UI only.
⚡ Enhancements
Look up a catalog entity by its identifier
Data source reads now return each object's catalog identifier, and a new POST /entities/lookup endpoint resolves a set of those identifiers to their catalog entries in one call. This lets your own tooling join against the catalog without reconstructing object names.
Recent run history on the scheduler job list
Each job on the scheduler list shows a strip of its last 30 runs, so a job that has been failing intermittently is visible from the list instead of only from its detail page.
Available in the new UI only.
Faster ways around the Data Explorer and scheduler
Scheduler jobs can be searched by name, the Data Explorer's catalog rail can be resized, and entity catalog rows open a quick view without navigating away.
Available in the new UI only.
The Postgres schema browser shows what you can query
Browsing a Postgres connection now lists table partitions, and no longer lists indexes and sequences — neither of which you can read as an object.
The OpenAI cost dashboard is readable
Spend is now labelled with your API key names and project names instead of the raw identifiers returned by OpenAI.
🔧 Bug Fixes
SmartDiff column mapping on Azure Blob, S3 and Google Cloud Storage
Saved column mappings on blob connections stopped matching after a change to how blob objects are identified, so every object looked stale and the mapping step returned an empty result with no explanation. Mappings resolve again. An object whose metadata genuinely cannot be read is now reported as such rather than dropped silently, and the new UI's mapping screen shows that reason in place of a blank result.
Date-range filters used your browser's timezone
SmartDiff and Drift date filters computed "today" in the viewer's local timezone while the data behind them is recorded in UTC, so a run near midnight could fall outside the range that should have contained it. Both now use UTC calendar days.
Available in the new UI only.
A deleted definition reported success instead of saying it was gone
Opening a definition that had since been deleted returned a successful, empty response. It now reports that the definition was not found; the new UI shows that message with a refresh action.
Refreshing a connection's objects now updates search
After refreshing the object list on a connection, search results kept the old set until the next full sync. The search index is updated as part of the refresh.
Reading an object's definition returned nothing for procedures, views and functions
When an object was requested by name alone, the platform assumed it was a table, so procedures, functions and views came back with an empty definition and a success status. The requested object type is now honoured, and a result cached under the wrong type no longer masks it.
SQL Server objects with unusual names
Object names containing reserved words, spaces or special characters failed during drop and catalog operations because they were not quoted, and grouping over rows containing NULLs could return wrong results. Catalog queries on very large SQL Server instances are also bounded now, so browsing a big catalog no longer runs away.
Deleting a single object on connectors that delete in bulk
Deleting one object on a connector that only supports bulk deletion returned a server error. It now works.
GitHub: reading a directory path
Reading metadata for a path that points at a directory rather than a file failed on the GitHub connection. It now returns the directory listing.
Two tables with the same name in different databases were treated as one
On a connection exposing several databases, identically named objects in identically named schemas shared an internal identity, so one silently overwrote the other on every sync. Each object now gets its own identity, derived from its full name including the database.
Entities silently missing from lineage
When an incoming entity collided with an existing one on its qualified name, lineage reported a successful write and saved nothing. The collision is now reported instead of swallowed.
BigQuery connections, workload listings and asynchronous deletes
Three errors seen in production are fixed: a BigQuery connection failing with an unreadable parsing error, listing workload items on a connector with no workload definition failing outright rather than returning an empty list, and a failure during asynchronous data source deletion.
Shares belonging to a deleted user
Deleting a user left the resources they had shared visible in every recipient's shared list, where opening one failed, and left grants they had received attached to an account that no longer exists. Both are now cleaned up with the user.
Secret fields in connection forms
Every secret field in a connection form carried the same label, and optional secret fields were treated as required, so a connection could not be saved without filling in credentials it did not need. Each field is now labelled by its own key, and optional fields are genuinely optional.
Available in the new UI only.
🔒 Security
Server logs could be downloaded by any signed-in user
Downloading the server logs carried no role check at all, so any signed-in user could retrieve them; reading them required an administrator, but an administrator of any tenant. The logs are one shared set of files for the whole server, not per-tenant records.
Downloading and reading server logs, and the engine cache diagnostic, are now limited to administrators of the default tenant. Cross-tenant privileged accounts are exempt from that tenant check and keep their access unchanged. This narrows access: an ordinary administrator in any other tenant who could previously read the logs now receives a "not authorized" response.
Pre-diff criteria expressions ran with unrestricted built-in functions
A pre-diff criteria expression was evaluated with Python's full set of built-in functions available, so a saved criteria could do more than narrow rows. Expressions are now limited to 25 data-handling functions: str, int, float, bool, len, abs, round, min, max, sum, list, dict, set, tuple, sorted, range, isinstance, format, map, filter, zip, enumerate, type, any and all.
Check your saved criteria. An expression that calls anything outside that list no longer runs, and it fails quietly — the criteria is skipped and the diff runs over all rows, with no error on screen. Review any criteria that uses a function not named above and rewrite it before your next run.
Upgrade Instructions
Deployment
Pull the latest Docker image.
Post-deployment
- Refresh the browser after upgrade
- Remove any calls to the per-data-source lineage sync endpoints listed under Breaking Changes
- Object identifiers are re-minted on each connection's next full sync, as part of the same-name fix described under Bug Fixes. If your own tooling stored identifiers returned by
POST /entities/lookupor by a data source read, re-fetch them after that sync rather than reusing the old values
Known Issues
Same-named tables still merge in the lineage graph: objects are now identified correctly in the catalog, but the lineage graph applies a second uniqueness rule based on display name, so two identically named tables from different databases on one connection still appear as a single node there. A fix is planned for a future release.
Support
For technical questions or issues, please contact our support team.
Released by Team Datadios | Document version: 1.0