The info in this doc only applies to Redshift data warehouses.
Because of the continuous and low-latency nature of Stitch, data will constantly be in flux in your data warehouse. In this article, we'll touch on how Stitch organizes your data.
When you initially create an integration, you have the ability to define the name of the integration and the schema that will be created in your data warehouse. This schema is where the tables for the integration will be stored.
The same name can be used for the integration's display name (what shows up on the Stitch Dashboard) and the schema name, or you can choose to name them separately. For more info about how schema naming works in Stitch, click here.
Here's an example of how an integration's data will be stored:
The tables in the integration schemas are the ones you'll interact with using an analysis integration.
It's important to note that Redshift doesn't currently support storing nested data as-is. To compensate for this, Stitch will de-construct nested records and create subtables. This can impact your row count and your querying strategy.
For an in-depth explanation of how this works, click here.
To fully understand the best way to interact with your data, we recommend you read on to learn what happens during data replication, how table structural changes are handled, and how nested data structures are handled by Stitch.