Hi, I have an airbyte connection to snowplow db in...
# replication-troubleshooting
l
Hi, I have an airbyte connection to snowplow db in postgres. I´ve set up the connection from google ads and it works perfectly. BUT I get two schemas: __airbyte__snowplow and snowplow. In the first one I get stg tables and in the second one I have raw tables, scd tables and the normalized ones. Which tables I should use and which ones I can delete? It is getting really messy
✍️ 1
👀 1
u
@[DEPRECATED] Marcos Marx turned this message into Zendesk ticket 2786 to ensure timely resolution!
s
The
scd
tables are required for incremental syncs, if you delete those then Airbyte will do a full refresh on the next sync.
raw
tables can be useful if you want to do custom transforms on the data, or if you need to debug the sync, but if the sync is working and you don't need to do further processing then they can be safely deleted The normalized tables are the final product, they are for your use, if you don't need the data then they can be removed too. I am still looking into whether
stg
can be deleted, will reply with my update
stg
table can be removed as well, as long as the sync (including normalization) is successful 🙂
l
Thanks for the answer. But in the next sync they will appear again?
My main probles is that due to the json blob, tabless that have size of 5mb appear in destination as 50mb. So I'm trying to find a solution.
Maybe you have encountered this problem in the past
s
Yes, in the next sync they will appear again Do you mean that it reaches 50mb because of duplication in `raw`/`scd` /`stg` tables?
l
I mean that each one of the raw, scd and stg table size is 50mb whereas in source the table's size is 5mb. I read in the forum it's due to the json blob, but it's impossible. Is there any way to reduce it?
s
Oh I see, at the moment there isn't really any way to optimize this. 😞 if you have the time please submit a request to improve performance! Using incremental syncs can save on API limit/network costs, however it looks like you're already using them. You could also potentially skip the destination connector's normalization step to save disk space, this would only leave the airbyte raw table, however you might have to use dbt or transform in some other way to get the data structured in a useful way and it would still take more space than the final table's 5mb.