How can I export Query Store data?
First of all, you might be able to get acceptable performance with queries directly against the query store catalog views by updating stats, adding query hints with plan guides, or changing the database compatibility level / CE.  See the answers from Forrest and Marian here: 

Never ending Query Store search



If you're on SP1 or greater, the simplest approach would be to use DBCC CLONEDATABASE - which includes statistics, query store data, and schema objects - but none of the actual data from the tables.



Otherwise, for exporting, one approach would be a simple SELECT...INTO from the query store views to the "sandbox" database.  These are the relevant views.

The basic approach would be like this:

SELECT * INTO Sandbox.dbo.query_store_runtime_stats FROM sys.query_store_runtime_stats;
SELECT * INTO Sandbox.dbo.query_store_runtime_stats_interval FROM sys.query_store_runtime_stats_interval;
SELECT * INTO Sandbox.dbo.query_store_plan FROM sys.query_store_plan;
SELECT * INTO Sandbox.dbo.query_store_query FROM sys.query_store_query;
SELECT * INTO Sandbox.dbo.query_store_query_text FROM sys.query_store_query_text;
SELECT * INTO Sandbox.dbo.query_store_wait_stats FROM sys.query_store_wait_stats;


The nice thing about this approach is that:


you'll only get the data you need (1000 MB)
you can add indexes to support your reporting queries, because these are actual tables
they won't have the unusual memory scanning behavior that leads to poor performance against the actual views (again because they are actual tables)


Note: the SELECT...INTO queries shouldn't drive up CPU like the built-in query store reporting queries, because they won't have the problematic joins that cause repeated access to the in-memory TVFs

you can keep different versions of the data (for different CU levels, etc) by changing the table names, or adding a column to the tables that indicates the data and / or version of SQL Server that was used for that import


The "con" of this approach is that you can't use the query store user interface.  A workaround for that would be to use profiler or extended events to capture the queries being executed by the user interface for the specific reports you need.  You could even do this capture in a non-prod environment, as the queries should be the same.



Warning: this is potentially a really bad idea.  There's a reason you can't normally write to these tables.  Special thanks to Forrest for mentioning the possibility to me.

If you really want to be able to use the user interface, you can actually load the base Query Store tables with data while connecting via the DAC.  Here's what worked for me.

Reminder: you have to be using a DAC connection to do this, otherwise you'll get errors related to the sys.plan_persist_* tables not existing

USE [master];
GO
CREATE DATABASE [Sandbox];
GO

USE [YourSourceDatabaseWithTheQueryStoreInfo];
GO

BEGIN TRANSACTION;

INSERT INTO Sandbox.sys.plan_persist_runtime_stats SELECT * FROM sys.plan_persist_runtime_stats;
INSERT INTO Sandbox.sys.plan_persist_runtime_stats_interval SELECT * FROM sys.plan_persist_runtime_stats_interval;
INSERT INTO Sandbox.sys.plan_persist_plan SELECT * FROM sys.plan_persist_plan;
INSERT INTO Sandbox.sys.plan_persist_query SELECT * FROM sys.plan_persist_query;
INSERT INTO Sandbox.sys.plan_persist_query_text SELECT * FROM sys.plan_persist_query_text;
INSERT INTO Sandbox.sys.plan_persist_wait_stats SELECT * FROM sys.plan_persist_wait_stats;
INSERT INTO Sandbox.sys.plan_persist_context_settings SELECT * FROM sys.plan_persist_context_settings

COMMIT TRANSACTION;
GO

USE [master];
GO
ALTER DATABASE [Sandbox] SET QUERY_STORE = ON (OPERATION_MODE = READ_ONLY);


Note: if you're on SQL Server 2016, you'll need to remove the line about wait stats - that catalog view wasn't added until SQL Server 2017

After doing that, I was able to use the Query Store UI in SSMS to view info on the queries from the source database.  Neat!

It's important to load the data into the Sandbox database with Query Store off, and then turn Query Store on in read only mode.  Otherwise QS ended up in an error state, and this was written to the SQL Server error log:


  Error: 12434, Severity: 20, State: 56.
  The Query Store in database Sandbox is invalid, possibly due to schema or catalog inconsistency.




I also noticed that this doesn't work if there are in-memory OLTP (Hekaton) tables in the source database.  No matter what I do, Query Store ends up in the "Error" state with this message in the error log:


  Error: 5571, Severity: 16, State: 2.
  Internal FILESTREAM error: failed to access the garbage collection table.


You may be able to work around that by adding a memory-optimized filegroup to the Sandbox database, I haven't tried that yet.