User Story takes longer than the sprint. Extend sprint or other options ?

I'm going to vote on your options and then give my real opinion.

Option 3 is the only one I see as wrong.

Options 1 and 2 imply that you are actually refining the stories into workable units.  Here is a quote from the Scrum Guide section on the Product Backlog (emphasis added by me).

Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be "Done" within the Sprint time-box. 

Find ways to slice the work into smaller increments where delivery of that increment provides some value to the customer and can illicit feedback.  In your example, how about delivering a way to see 1 data element in a table on the screen where other columns are labeled but not populated in the first iteration?  Show it to the stakeholders and ask if that is the way they expected it to be presented. What if they were expecting a map that showed the value?  Adjust to their feedback and deliver that plus a second data element.  Incrementally provide the final solution that they want. 

A Spring increment is expected to be "potentially releasable" so it doesn't have to be a complete feature. The Scrum Guide mentions in many places that it is up to the Product Owner when to release.  And what they release is as specific increment or the sum of multiple increments. They will release something that they see provides immediate value to the stakeholders. It may not be the full solution but it will provide immediate value. 

Now, having said all of that, it isn't uncommon for some of my teams to find stories that aren't finished at the end of the Sprint.  You can't anticipate what you will find during the Sprint that could cause this.  But if they are going into a Sprint with the understanding that it won't be completed, that is something that needs to be discussed to determine if there is any way to resolve that.  Otherwise if that practice is common and accepted, it will become difficult to find any way to determine any kind of consistent velocity that the PO can use for communicating outwards.  Again from the Scrum Guide, this time from the section on the Sprint Review (and again emphasis by me).

• The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);

If the team constantly carries over stories, how can the PO have any way of projecting?

Maybe you can have a look at some splitting options :

http://agileforall.com/wp-content/uploads/2018/02/Story-Splitting-Flowchart.pdf

• As a X user we want to see our data by region so that we can understand our costs better.

What risks or unknowns are present in this story, and what are the smallest experiments you could conduct in order to mitigate them?

To deliver this requires, three developers working sequentially.

1. Load region values into Regional databases (1 sprint)
2. Update scripts to pull data from regional databases to master database (1 sprint)
3. Create report (1 sprint).

Why are developers working sequentially?

Why does it take 1 sprint for each of these tasks?

Further to what others have said, I would suggest breaking it into pieces that can be delivered within a sprint.

How might you vertically split the Product Backlog items, so that each PBI creates a smaller piece of the database, includes some portion of the scripts, and assembles a piece of the report?  The Increment only has to be 'potentially shipable' but meet the Definition of "Done".

At the Sprint Reviews would the business stakeholders be able to inspect a database or scripts?  Probably not. 

In addition to the advice given above, I'd like to point these:

• First of all, are you using Scrum? You mentioned you had started to "use Agile", but Agile in itself isn't a method, nor a framework.
• Do you have sprint goals? How does the team work against it?
• "We often have user stories which cannot be delivered in one sprint, due to our architecture." - user stories mean nothing if there's no ultimate value for the business. Do you have a product owner (business representative working with the development team? 
• "due to our architecture" - have seen many of these reasons (or variations thereof) given as an excuse. How about find ways, given your architecture, to bring value on a regular basis (release frequently) 
• How long are your sprints? I find it hard to believe it takes close a week (or even up to 4 weeks) for a single developer to "Load region values into Regional databases" or anything else for that matter given your circumstances. 
• Do you have a work in progress limit? Developers shouldn't start too many tasks and have a slow progress, especially when their work precedes another one's
• Do you have backlog refinement? Who manages the backlog anyway? Are the stories deemed ready for sprint planning? Is the team aiming to meet the INVEST guidelines?
• Is the sprint backlog ordered - prioritized? Is the team pulling up work according to the order, especially given the "sequential" process required
• Do you have daily meetings (standups) where the team inspects and adapts accordingly?
• Where "sequential" work is needed, are the developers cooperating daily (hourly even!), looking at what the first (or second, then the third) is doing in order to share knowledge, align themselves and find the best way to deliver?
• ...

Thanks for the feedback.

I'll illustrate my original scenario.

Multiple Customer Sites  > Multiple Country specific Databases  > One European Data Vault >  European Data Mart > Analytics.

Developer A works on extracts from the customer sites (some extracts are written by external vendors) 

Developer B works on the European Data Vault 

Developer C works on the European Data Vault 

Developer B works on European Data Mart

Developer D works on Analytics

So using the 'Region' field example.  It may need to be added to multiple extra programs.  Then develop A to D need to action separate tasks, sequentially.

To answer some of the specific questions.

We're using Scrum.

Although we have 1 sprint it's split into three logical divides with different product owners (confusing I know).

Core > Data Management > Product.  Only the user stories labelled 'Product' are associated with a real business purpose.

•"due to our architecture" - have seen many of these reasons (or variations thereof) given as an excuse. How about find ways, given your architecture, to bring value on a regular basis (release frequently)

  >>> I think this is a fair point and this is something I need to progress for sure.

•How long are your sprints? I find it hard to believe it takes close a week (or even up to 4 weeks) for a single developer to "Load region values into Regional databases" or anything else for that matter given your circumstances.

 1 week (Well the region was more a hypothetical example - maybe not a good one)

•Do you have backlog refinement? Who manages the backlog anyway? Are the stories deemed ready for sprint planning? Is the team aiming to meet the INVEST guidelines?

 yes, product owners. (I'd never heard of INVEST before your comment, will feed this back to the team)

•Is the sprint backlog ordered - prioritized? Is the team pulling up work according to the order, especially given the "sequential" process required

 Yes

•Do you have daily meetings (standups) where the team inspects and adapts accordingly?

 Yes

•Where "sequential" work is needed, are the developers cooperating daily (hourly even!), looking at what the first (or second, then the third) is doing in order to share knowledge, align themselves and find the best way to deliver?

 I think this is a case of WIP.

So as well as taking it upon myself to better understand why everything takes so long to develop, I will also see if our user stores can be split up.

You may also want to consider that 1 week sprints are not long enough.  In my experience 1 week has never really been enough time to do any real work.  I have worked with a team that did 4 week sprints but that was really rare situation.  Most of my teams settle in on 2 week sprints because that is long enough to get work done but not so long that it is hard to plan or show progress.  I also think that a 2 week sprint might be more realistic given your example. 

An suggestion on how to break up your European Vault problem is to deliver 1 or 2 countries at a time with the entire system.  That way you can validate the process will work and that the report is going to produce correct information.  Much easier to adjust when there is less data than trying to do it after the entire EU is loaded up. After you get the process and end result correct, it should be much easier to load up the rest of the DB. 

You may have to do more than 1 thing to make this "better" for you.  Scrum is about inspect and adapt based on information you have.  Work with your team to come up with adaptions(experiments) that they feel could help and the Retrospective is intended for this purpose.  Try out and ideas.  At most any of the experiments only have to live for a sprint, maybe two if still not sure.  If you find something that the team feels is an improvement, stick to it.  But be warned that even that adaption may need to change as the team gets better at this. 

I applaud you for taking this on and being willing to ask for help.  I see that as a sign of a good Scrum Master.  So even if you aren't officially a SM, you have the potential to become a very good one. 

Good luck!

Here is a similar but possibly slightly different challenge I faced in the recent past

• Team is working on enhancements of a legacy code
• Multiple developers (coders) can't work on PBI in parallel; only testing work (scenario identification, automation) can be progressed concurrently
• Code level analysis takes some time as legacy code is not clean and due to lack of unit tests; automation coverage is very low
• This makes it difficult for team to complete a story (as per DoD) within 2 weeks sprint
• Stories are already small and meet INVEST. Splitting them further is not easy in most of the cases
• Too much splitting increases manual deployment & manual testing overhead
• Sprint Review is primarily to check progress and make forecast and feedback on functional feature is done at a story level than at sprint level
• Since product was in KLO phase (with modernization work going on in parallel) organization is not interested to invest in automation

We discussed few options

1) Split work into spike (for analysis) and stories; however it would mean team would nearly have 1 spike for 1 or couple of stories

2) Follow Kanban(Scrum-Ban?) instead of a Scrum. This would include lightweight on-demand planning, review sessions. Daily connect would help collaboration and periodic retrospective would help teams to inspect their way of working, culture, communication etc.

I request experts to kindly suggest other / better options based on your experience.