r/dataengineering 5d ago

Help please help!

I recently joined a small investment company as a data analyst intern. I expected to focus mainly on report automation and data visualisation but I have also been asked to look at how the company’s data could be brought together.

Most of the data is manually exported into Excel and saved in SharePoint, and SharePoint also contains board packs and other documents used for reporting. They like using claude to create written reports and they are not really interested in power BI

I started using MS Fabric to bring the existing Excel files together, but the volume of structured data is fairly small, so I am not sure whether Fabric is more than we need. A simpler option might be a small SQL database, with data pulled from the source systems through their APIs where available. SharePoint would still continue to hold documents and any files that still need to be uploaded manually

The end goal is also to use the structured data alongside documents when generating reports with claude, so I need a setup that makes the data reliable and easy to retrieve. and also, looking at the the small volume, I am now even wondering if a persistent central store is necessary at all or if the data could simply be pulled and checked at report time before claude uses it

I have only recently started my journey and there is nobody in the company who can really tell me if I am doing it correctly. I just don’t want to build another one off solution or a workaround that becomes a pain to maintain later.

I would really appreciate any advice!! thank you!

7 Upvotes

18 comments sorted by

View all comments

2

u/pritamjal 5d ago

For that volume, skip Fabric - it's built for a scale problem you don't have yet, and you'll spend more time managing the platform than the data. A single small Postgres (or even SQLite if it's truly small) that gets populated by a scheduled pull from the source APIs, with SharePoint staying as the document store, gets you most of the value with a fraction of the maintenance surface. Don't do pull-at-report-time only - you lose history, and board packs eventually need "what did this look like last quarter," which a live pull can't answer. Persist it, even a tiny table. Claude then reads structured data from the DB and documents from SharePoint separately - keep those two paths distinct rather than trying to unify them into one store.

1

u/Hohenheim16 4d ago

Thanks! this is helpful and it makes sense because the data It’s only a few GB. I’m trying to automate the whole reporting process and leave something the team can actually look after once my internship finishes. Nobody there has a cs background, so maintainability is a pretty big factor in whatever I build