Skip to main content
Question

Lineage Best Practice - any ideas?

  • October 9, 2026
  • 1 reply
  • 16 views

may_kwok
Rocket Pioneer L1
Forum|alt.badge.img+4

Hello fellow data enthusiasts,

We’re starting to look into the lineage feature of Ataccama and we want to get it right. Calling other customers who already use lineage, and also if a representative from the Product team could chime in, that’d be amazing!

I’m reviewing how our data catalog sources / connections are set up, and how that needs to / doesn’t need to relate to how the scan plans are configured.

For the catalog, for example:

  • Sources: A source system. I’m in the insurance business, we’d have Policy Admin systems, Claims systems, Accounting systems, Datawarehouse etc. I’d put each one of them separately
  • Connections: Possibility of multiple connections for a given system, as each system might have separate databases. We use MS SQL and we do have a database server that has multiple databases sitting in it, and data moves between them.
  • SQL CIs / VCIs: These go under the source into the workspace / folders

Does this have any bearing as to how the lineage scan plans are set up?

  • One scan plan for the database server
    • Lineage import one scan plan into multiple connections
  • One scan plan for each database, so there will be multiple scan plans
    • Lineage import each scan plan into multiple connections

 

Trying to balance a good user experience for my team, neatly organised on the platform so it doesn’t look chaotic, easy to manage and maintain, and of course reasonable performance.

Any ideas and input greatly appreciated!

1 reply

Forum|alt.badge.img

Hey ​@may_kwok 

Thanks for asking these questions. It depends on the case. The main questions to ask for MS SQL lineage are:

  • How many databases need to be scanned?
  • How large are my databases from a lineage perspective, and how much metadata needs to be scanned and parsed?

My recommendation is to create one scan plan per database for more granular control and better restartability in case of failure. If there are tens of databases to scan, I would likely create scan plans that group multiple databases together.
For a single huge database, you can also split the scan by target schemas and run multiple scans per database, but this is usually not needed.

Best regards

Frantisek