Slackbot
08/04/2026, 3:45 PMkapa.ai
08/04/2026, 3:45 PMv0.29.0 â v0.30.4). Upgrading is highly recommended before trying anything else:
# Using curl
curl -LsfS https://get.airbyte.com | bash -
# Or using Homebrew
brew upgrade abctl
Then verify: abctl version [Upgrading abctl]
2. Try a fresh install after upgrading After upgrading abctl, do a clean reinstall:
abctl local uninstall --persisted
rm -rf ~/.airbyte/abctl
abctl local install
[abctl reference]
3. Known root causes for ingress timeouts According to a GitHub issue tracking abctl reliability problems, there are a few known causes: [abctl reliability issue]
âĸ Resource constraints: No preflight checks exist for CPU/memory/disk. If your VM is under-resourced, pods take longer to start and the ingress verification times out (hardcoded at 1 minute).
âĸ Network/proxy issues: If you're behind a corporate proxy, image pulls can fail silently, causing later Helm timeouts. You may need to exec into the airbyte-abctl-control-plane container and configure proxy settings.
âĸ Image pull failures: Docker Hub rate limiting can cause silent failures that manifest as ingress timeouts.
4. If you're behind a proxy docker exec -it airbyte-abctl-control-plane bash
# Then test connectivity:
curl https://ifconfig.io
If that fails, you'll need to configure proxy settings inside the container. [nginx install issue]
5. Pin to a known-good chart version Some users have had success pinning to chart version 1.7.2:
abctl local install --chart-version=1.7.2
[Helm chart issue]
Important note: The ingress timeout is a known reliability issue with abctl on cloud VMs and constrained environments. Upgrading abctl to the latest version (v0.30.4) is the most important first step, as several ingress-related fixes were included in recent releases. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 3:50 PMdocker exec -it airbyte-abctl-control-plane bash it went to root (
root@airbyte-abctl-control-plane:/#), then I got an IP address (xx.xx.xxx.xxx) when running curl <https://ifconfig.io>kapa.ai
08/04/2026, 3:50 PMcurl https://ifconfig.io returned an IP address means your container has internet connectivity. So a proxy/network block is not the cause of your issue.
Based on the knowledge sources, here are the next steps to diagnose further:
1. Check pod status inside the container While still inside airbyte-abctl-control-plane, run:
kubectl get pods -A
Look for any pods in ImagePullBackOff, ErrImagePull, CrashLoopBackOff, or Pending state â these are common causes of ingress timeouts that don't get surfaced clearly. [abctl reliability issue]
2. Check logs of any failing pods kubectl logs <pod_name> -n <namespace>
Or using the kubeconfig from outside the container:
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl get pods
[abctl FAQ]
3. Upgrade abctl to v0.30.4 Your previous error output showed that v0.30.4 is available and highly recommended. This is still the most important step, as newer versions include improved diagnostics and reliability fixes. [abctl reliability issue]
4. Check your system resources The knowledge sources note that insufficient resources are a common silent cause of timeouts â with no preflight checks currently in place. Minimum recommended specs are:
âĸ At least 4 CPUs (8 recommended)
âĸ At least 8 GB RAM (16 recommended)
âĸ At least 20 GB disk
If your machine is constrained, try:
abctl local install --low-resource-mode
[abctl install issue]
Could you share the output of kubectl get pods -A from inside the container? That would help narrow down the exact cause. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 3:53 PMkapa.ai
08/04/2026, 3:54 PMRunning â
âĸ The bootloader is Completed â
(this is expected â it's a one-time init job)
âĸ The ingress-nginx controller is Running â
Your Airbyte installation appears to be healthy. The ERROR: Timed out waiting for ingress you saw earlier was likely a false failure â the ingress controller just took longer than the hardcoded 1-minute timeout to become responsive, even though it eventually came up fine. This is a known issue with abctl. [abctl reliability issue]
Try accessing Airbyte now Open your browser and navigate to:
http://localhost:8000
Or if you're on a remote VM, use the server's IP address on port 8000.
If the UI doesn't load Run this from outside the container to check the ingress:
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl get ingress
Going forward Since your cluster is healthy, upgrading abctl to v0.30.4 before your next install/upgrade is still strongly recommended, as it includes reliability improvements that may prevent this false timeout from occurring again. [abctl reliability issue] đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 3:57 PMkubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress-abctl nginx ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com,localhost,host.docker.internal 10.xx.xxx.xxx 80 41mkapa.ai
08/04/2026, 3:58 PMlocalhost, and host.docker.internal â
âĸ Address: 10.xx.xxx.xxx (internal IP assigned) â
âĸ Port: 80 â
Try accessing Airbyte Since you're on an EC2 instance, try opening in your browser:
http://ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com:8000
If it still doesn't load, check two things: 1. Verify the EC2 Security Group allows inbound traffic on port 8000
In your AWS Console, go to your EC2 instance â Security Groups â Inbound Rules and make sure port 8000 is open to your IP (or 0.0.0.0/0 for testing). [EC2 with abctl]
2. Confirm abctl was installed with the correct --host flag
By default, abctl only configures ingress for localhost. For EC2 access, it needs to be installed with your EC2 hostname explicitly: [EC2 with abctl]
abctl local install --host ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com --insecure-cookies
The --insecure-cookies flag is needed if you're running over plain HTTP rather than HTTPS.
Since your ingress already shows the EC2 hostname as a host, it looks like you may have already done this â so the Security Group rule on port 8000 is the most likely remaining issue. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 4:02 PMabctl , please give me more detail for EC2 Security Group allows inbound traffic on port 8000kapa.ai
08/04/2026, 4:02 PM8000
âĻ Source: Your IP address (e.g. My IP) for security, or 0.0.0.0/0 for open access (not recommended for production)
1. Click Save rules
Security note Airbyte strongly recommends securing your instance with TLS rather than running over plain HTTP, as plain HTTP exposes your password in clear text. [EC2 with abctl]
If you must run over HTTP, make sure you used the --insecure-cookies flag:
abctl local install --host ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com --insecure-cookies đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 4:06 PMkapa.ai
08/04/2026, 4:06 PMabctl local install --host ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com --insecure-cookies
2. The ingress timeout was a false failure As we identified earlier, all your pods were healthy (`Running`/`Completed`). The ERROR: Timed out waiting for ingress was likely a false negative due to the hardcoded 1-minute timeout in abctl on slower cloud VMs â not an actual installation failure. [abctl reliability issue]
What I'd suggest Try reinstalling now that you've upgraded abctl to `v0.30.4`:
abctl local uninstall
abctl local install --host ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com --insecure-cookies
Then access Airbyte at:
http://ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com:8000
I'm sorry I can't pinpoint exactly what changed when you configured the inbound rules, as the knowledge sources don't contain enough detail to explain that specific interaction. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 4:08 PMkapa.ai
08/04/2026, 4:08 PMt3.xlarge gives you 4 vCPUs and 16 GB RAM, which is a reasonable instance size for running Airbyte.
How it compares to recommendations Based on the knowledge sources:
âĸ CPU: 4 CPUs meets the minimum recommended spec of "4 or more CPUs" â
[OSS Quickstart]
âĸ RAM: 16 GB meets the recommended 8 GB minimum â
[OSS Quickstart]
âĸ Disk: Make sure you have at least 30 GB allocated, as connector images (~300 MB each) and logs can add up quickly [Scaling Airbyte]
Things to watch on a t3.xlarge âĸ Memory during syncs: The source worker reads up to 10,000 records in memory. For tables with large row sizes this can be significant. Monitor memory usage during syncs. [Scaling Airbyte]
âĸ No need for --low-resource-mode: That flag is intended for 2 CPU / 8 GB environments. Your instance is capable enough to run in normal mode. [OSS Quickstart]
âĸ Concurrent syncs: Make sure your instance can schedule up to 2 x <number of concurrent connections> pods at once. [Scaling Airbyte]
Overall, a t3.xlarge should be sufficient for testing and moderate production workloads with Airbyte. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 4:11 PMrm -rf ~/.airbyte/kapa.ai
08/04/2026, 4:11 PM~/.airbyte/ directory, including:
âĸ The kubeconfig (~/.airbyte/abctl/abctl.kubeconfig)
âĸ The cluster data
âĸ All Airbyte data (connections, sources, destinations, configurations)
This is more aggressive than the recommended cleanup command. [abctl reference]
The recommended approach is: abctl local uninstall --persisted
rm -rf ~/.airbyte/abctl
Note it only removes ~/.airbyte/abctl, not the entire ~/.airbyte/ directory. [abctl reference]
My recommendation for your situation You don't need to do this yet. Looking back at our conversation:
âĸ All your pods are healthy â
âĸ Ingress is configured correctly â
âĸ The timeout error was likely a false failure â
Instead, try first:
abctl local uninstall
abctl local install --host ec2-xx.xx.xxx.xxx.ca-central-1.compute.amazonaws.com --insecure-cookies
Only do a full wipe with rm -rf ~/.airbyte/abctl if the reinstall fails and you're comfortable losing all your existing Airbyte configuration. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 5:03 PMkapa.ai
08/04/2026, 5:03 PMabctl to the latest version (v0.30.4)
âĸ â
Installed with the correct --host and --insecure-cookies flags for EC2 HTTP access
âĸ â
EC2 Security Group configured for port 8000
Useful next steps âĸ Get your credentials to log in:abctl local credentials
âĸ Check your installation status anytime:abctl local status
âĸ Start moving data by setting up your first source, destination, and connection in the UI. [What's next]
Keep in mind âĸ Airbyte recommends securing your instance with TLS/HTTPS rather than running over plain HTTP long-term, as HTTP exposes your password in clear text. [EC2 with abctl]
âĸ Keep abctl updated â upgrading is as simple as re-running the install script:curl -LsfS https://get.airbyte.com | bash -
Good luck with your data pipelines! đ đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 5:07 PMrm -rf ~/.airbyte/ before, everything was wiped out, it will do full refresh to overwrite the old data in destination, right?kapa.ai
08/04/2026, 5:07 PMrm -rf ~/.airbyte/ and a Full Refresh Overwrite are two completely separate things.
What rm -rf ~/.airbyte/ actually wiped This command only removed your Airbyte configuration (connections, sources, destinations, credentials, kubeconfig, etc.) from your local EC2 instance. It did not touch any data in your destination (e.g. BigQuery, Snowflake, Postgres, etc.). [Data deletion]
> When you delete a connection in Airbyte, the data that has been synced to the destination will not be automatically deleted. The data that has already been synced will remain in the destination.
What happens when you re-sync When you recreate your connections and run a new sync, the behavior depends on the sync mode you configure:
âĸ Full Refresh | Overwrite: Will destroy all existing data in the destination table and replace it with fresh data from the source. [Full Refresh Overwrite]
âĸ Full Refresh | Overwrite + Deduped: Same as above but deduplicates by primary key. [Full Refresh Overwrite Deduped]
âĸ Incremental: Will append/update only new records on top of existing destination data.
Bottom line âĸ Your destination data is safe â rm -rf ~/.airbyte/ did not touch it â
âĸ Whether your next sync overwrites old destination data depends entirely on the sync mode you choose when recreating your connections, not on the rm -rf command itself. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 5:10 PMkapa.ai
08/04/2026, 5:10 PMMicky
08/04/2026, 5:11 PMkapa.ai
08/04/2026, 5:11 PMMicky
08/04/2026, 5:14 PMkapa.ai
08/04/2026, 5:14 PMupdated_at) [Incremental Append Deduped]
> Deduped means that data in the final table will be unique per primary key. This is determined by sorting the data using the cursor field and keeping only the latest de-duplicated data row.
What this means in practice So you get the best of both worlds:
âĸ â
Full history preserved in the raw table
âĸ â
Clean, deduplicated view in the final table
âĸ â
No duplicate primary keys in the final table [Incremental Append Deduped] đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 5:16 PMkapa.ai
08/04/2026, 5:16 PMfetchSize batching)
âĸ Record size (larger rows = slower throughput)
âĸ Source/destination combination
âĸ Your EC2 instance network latency to source and destination
âĸ Whether this is the first sync (full load of all 500K records)
What you can do right now Check the sync progress in the Airbyte UI logs to see the current records read count, or run: [Connection Timeline]
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl logs -f <source-pod-name>
Since this is likely your first sync (full load), I'd give it more time before worrying â 18 minutes for 500K records on a first sync is not alarming. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 5:40 PMkapa.ai
08/04/2026, 5:40 PM_AIRBYTE_EMITTED_AT column (an older metadata field), but it cannot because it is being used as a clustering key in your destination table. [Forum Post]
Why this happens _AIRBYTE_EMITTED_AT is a pre-Destinations V2 metadata field. Its equivalent in the current Destinations V2 is _airbyte_extracted_at. When Airbyte tries to migrate/update the schema, it cannot drop the old column because it belongs to a clustering key. [Airbyte Metadata Fields]
How to fix it The fix depends on your destination:
For Snowflake:
Manually drop the clustering key on the affected table first: [Forum Post]
ALTER TABLE <your_table> CLUSTER BY ();
Then drop the column:
ALTER TABLE <your_table> DROP COLUMN "_AIRBYTE_EMITTED_AT";
Then reset and re-sync the connection in Airbyte.
For Redshift:
Disable the sort key first: [Forum Post]
ALTER TABLE <your_table> ALTER SORTKEY NONE;
Then retry the sync.
Important notes âĸ â ī¸ Back up your data before making any manual DDL changes to destination tables
âĸ After making the changes, you may need to reset the connection in Airbyte and re-sync
âĸ This is a known backward compatibility issue when upgrading connectors
Could you share which destination you are using (Snowflake, Redshift, BigQuery, etc.)? That would help narrow down the exact fix for your case. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 5:41 PMkapa.ai
08/04/2026, 5:42 PMALTER TABLE <your_schema>.<your_table> CLUSTER BY ();
Step 2: Drop the old column
ALTER TABLE <your_schema>.<your_table> DROP COLUMN "_AIRBYTE_EMITTED_AT";
[Forum Post]
Good news â this is being fixed in Airbyte A recent pull request (#82272) specifically addresses this by removing the column DROP logic during schema evolution in the Snowflake destination connector (version 4.0.47 onwards). This means: [Snowflake PR]
> Airbyte will stop dropping columns during schema evolution in the Snowflake destination entirely.
So after upgrading to the latest Snowflake destination connector, this warning should no longer appear.
Steps to fully resolve right now 1. Run the SQL above on your affected Snowflake table(s)
2. Reset the connection in Airbyte UI
3. Re-sync the connection
4. Upgrade your Snowflake destination connector to 4.0.47 or later to prevent this from happening again
â ī¸ Make sure to back up your data before making any manual DDL changes to your Snowflake tables. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 5:48 PMkapa.ai
08/04/2026, 5:49 PMHeartbeat not progressing warnings, with time since last progress increasing every 10 seconds (1123s â 1133s â 1143s â 1153s...)
âĸ This means the CDC heartbeat has not progressed for ~18+ minutes
âĸ There is also a line showing: Received offset commit request on 'LSN{1C04/340000F8}'
What this means The connector is stuck in a heartbeat not progressing state â similar to the issue described in GitHub issue #49803. The sync is running but not making progress. [Github Issue]
What to do 1. Increase the initial CDC waiting time
Since your dataset has 500K+ records, the connector may need more time. Set the initial wait time to a higher value (e.g. 600 seconds): [Postgres Troubleshooting]
> If you know there are database changes to be synced, but the connector cannot read those changes, the root cause may be insufficient waiting time.
2. Check your replication slot
Run this on your Postgres source to check if the replication slot is healthy:
SELECT slot_name, active, restart_lsn, confirmed_flush_lsn
FROM pg_replication_slots;
3. Reset the connection
If the heartbeat continues to not progress, try resetting the connection in the Airbyte UI and re-syncing. This clears the saved LSN offset and starts fresh. [Postgres Troubleshooting]
The sync will eventually auto-close itself once the heartbeat timeout is reached, but resetting and re-syncing is the cleaner approach here. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 5:53 PMkapa.ai
08/04/2026, 5:53 PMconfirmed_flush_lsn (1C04/340000F8) is ahead of restart_lsn (1C04/340000C0). This matches exactly the issue described in the logs from your previous screenshot where the LSN commit was on 1C04/340000F8. [Github Issue]
This is the known bug where:
> The confirmed_flush_lsn is advancing beyond the saved state LSN, causing the connector to get stuck.
Recommended Fix 1. Check your Postgres source connector version
The fix was released in version `3.7.2`: [Github Issue]
> Airbyte released 3.7.2 which fixes this issue
2. If not on 3.7.2, upgrade your source-postgres connector in the Airbyte UI:
âĸ Go to Sources â select your Postgres source
âĸ Check the connector version and upgrade to 3.7.2 or later
3. As an immediate workaround, set up a heartbeat table to keep the LSN advancing: [Postgres Troubleshooting]
CREATE TABLE airbyte_heartbeat (
id SERIAL PRIMARY KEY,
timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
text TEXT
);
ALTER PUBLICATION <publicationName> ADD TABLE airbyte_heartbeat;
Then configure the Debezium heartbeat query in your Postgres source settings:
INSERT INTO airbyte_heartbeat (text) VALUES ('heartbeat')
4. Reset the connection in Airbyte UI and re-sync after upgrading the connector. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 5:58 PMkapa.ai
08/04/2026, 5:58 PM3.7.2 fix. So the connector version is not the issue here.
What's likely causing the problem Looking back at your logs and replication slot results, the issue is the confirmed_flush_lsn advancing beyond the saved state LSN â even on newer connector versions. There is an open PR (#79671) that addresses this specifically: [Fix CDC LSN]
> CDC syncs will correctly advance the replication slot's confirmed_flush_lsn, preventing unbounded WAL growth on the source PostgreSQL database. This is especially important after initial snapshots where only the lsn field is present in the Debezium offset.
Immediate steps to try 1. Set up a heartbeat table (most effective workaround right now): [Postgres Troubleshooting]
CREATE TABLE airbyte_heartbeat (
id SERIAL PRIMARY KEY,
timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
text TEXT
);
ALTER PUBLICATION <publicationName> ADD TABLE airbyte_heartbeat;
Then in your Postgres source Advanced settings â Debezium heartbeat query:
INSERT INTO airbyte_heartbeat (text) VALUES ('heartbeat')
2. Reset the connection in Airbyte UI:
âĸ Go to Connections â select your connection
âĸ Click Reset to clear the saved LSN state
âĸ Then trigger a new sync
3. Change Invalid CDC position behavior to Re-sync data instead of Fail sync as a temporary measure to avoid hard failures while the LSN issue resolves itself. [Github Issue]
The heartbeat table is the most reliable workaround until a full fix is released in a newer connector version. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 6:06 PMairbyte_heartbeat table directly in the current schema?kapa.ai
08/04/2026, 6:06 PMairbyte_heartbeat table in any schema you prefer â the documentation uses public schema as an example: [Postgres Troubleshooting]
> You can put your heartbeat table anywhere. I just put mine in my public schema.
Recommendation You have two options:
Option 1: Create it in the public schema (simplest)
CREATE TABLE public.airbyte_heartbeat (
id SERIAL PRIMARY KEY,
timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
text TEXT
);
ALTER PUBLICATION <publicationName> ADD TABLE public.airbyte_heartbeat;
Then set the heartbeat query to:
INSERT INTO public.airbyte_heartbeat (text) VALUES ('heartbeat')
Option 2: Create it in your current schema
CREATE TABLE <your_schema>.airbyte_heartbeat (
id SERIAL PRIMARY KEY,
timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
text TEXT
);
ALTER PUBLICATION <publicationName> ADD TABLE <your_schema>.airbyte_heartbeat;
Then set the heartbeat query to:
INSERT INTO <your_schema>.airbyte_heartbeat (text) VALUES ('heartbeat')
Important notes âĸ â
The schema location doesn't matter as long as it's added to the publication
âĸ â
You do not need to sync the heartbeat table in Airbyte â just adding it to the publication is enough
âĸ â
Make sure your Airbyte Postgres user has write access to whichever schema you choose đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 6:18 PMkapa.ai
08/04/2026, 6:18 PM184.62 MB | 522,451 records loaded | 26m 57s. Here is what that means:
Why it shows those metrics even though it was cancelled The sync was manually cancelled by you (Default User cancelled a sync), but Airbyte still reports the data that was successfully loaded before the cancellation happened. [Connection Timeline]
> Cancelled â Someone cancelled the sync before it finished.
This means:
âĸ â
522,451 records were successfully loaded to Snowflake before you cancelled
âĸ â
184.62 MB of data was moved during those 26m 57s
âĸ â The sync did not fully complete â there may be more records remaining in the source that were not yet synced
What the metrics represent [Connection Timeline] Bottom line The data that was loaded (522,451 records) is already in your Snowflake destination. When you run the next sync, since you are using Incremental | Append + Deduped, Airbyte will pick up from where it left off and sync the remaining records without duplicating what was already loaded. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 6:20 PMkapa.ai
08/04/2026, 6:20 PMHeartbeat not progressing issue is still present. If you don't set up the heartbeat table fix first, the next scheduled sync may get stuck again in the same way.
Recommendation Before waiting for the next scheduled sync:
1. Set up the heartbeat table as discussed
2. Reset the connection in Airbyte UI
3. Then either wait for the scheduled sync or manually trigger a new sync to confirm it works correctly
This way you avoid the same heartbeat issue repeating on the next scheduled run. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 6:28 PMairbyte_extracted_at and airbyte_cdc_updated_at for the tables are the same when syncing datakapa.ai
08/04/2026, 6:28 PM_airbyte_extracted_at and _ab_cdc_updated_at would show the same values in your case. However, here is what the knowledge sources do tell us about these two fields:
What each field means Why they could appear the same These two values can coincidentally match if:
âĸ The records were inserted and synced at nearly the same time â i.e. Airbyte ran the sync very shortly after the database transaction occurred
âĸ This is more likely on a first sync where all records are loaded at once
What to check Run this query in Snowflake to see if they are truly identical or just appear similar:
SELECT
_airbyte_extracted_at,
_ab_cdc_updated_at,
_airbyte_extracted_at = _ab_cdc_updated_at AS are_equal
FROM <your_schema>.<your_table>
LIMIT 100;
If they are consistently identical across all records, I'd recommend joining the Airbyte Community Slack or opening a support ticket with your connector versions and sync logs for a deeper investigation. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 6:31 PMkapa.ai
08/04/2026, 6:31 PMairbyte_heartbeat table
2. â
Added it to your publication
3. â
Configured the Debezium heartbeat query in your Postgres source settings
Otherwise the next sync may get stuck again in the same way regardless of how much data needs to be synced. [Postgres Troubleshooting] đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 6:46 PMkapa.ai
08/04/2026, 6:46 PMCannot drop column '_AIRBYTE_EMITTED_AT' which belongs to a clustering key
Find all tables with _AIRBYTE_EMITTED_AT column in Snowflake Run this query in Snowflake to find all affected tables:
SELECT
table_schema,
table_name,
column_name
FROM information_schema.columns
WHERE column_name = '_AIRBYTE_EMITTED_AT'
AND table_schema = '<your_schema>'
ORDER BY table_schema, table_name;
Or across all schemas in your database:
SELECT
table_schema,
table_name,
column_name
FROM information_schema.columns
WHERE column_name = '_AIRBYTE_EMITTED_AT'
ORDER BY table_schema, table_name;
Then fix each affected table For each table returned, run: [Forum Post]
-- Step 1: Remove the clustering key
ALTER TABLE <your_schema>.<your_table> CLUSTER BY ();
-- Step 2: Drop the old column
ALTER TABLE <your_schema>.<your_table> DROP COLUMN "_AIRBYTE_EMITTED_AT";
After fixing all tables 1. â
Reset the connection in Airbyte UI
2. â
Trigger a new sync to confirm the error is resolved
3. â
Upgrade your Snowflake destination connector to the latest version to prevent this from recurring
â ī¸ Make sure to back up your data before making any manual DDL changes. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 6:52 PMairbyte_emitted_at column and why some tables don't have itkapa.ai
08/04/2026, 6:52 PM_AIRBYTE_EMITTED_AT is a pre-Destinations V2 metadata field. Tables that have it were created before your Snowflake destination was upgraded to Destinations V2. Tables that don't have it were created after the upgrade and use the newer _airbyte_extracted_at field instead. [Airbyte Metadata Fields]
Fix all 100 tables at once Instead of running the fix manually for each table, you can generate and execute the statements dynamically:
-- Step 1: Generate ALTER statements for all affected tables
SELECT
'ALTER TABLE ' || table_schema || '.' || table_name || ' CLUSTER BY ();' AS remove_cluster,
'ALTER TABLE ' || table_schema || '.' || table_name || ' DROP COLUMN "_AIRBYTE_EMITTED_AT";' AS drop_column
FROM information_schema.columns
WHERE column_name = '_AIRBYTE_EMITTED_AT'
AND table_schema = '<your_schema>'
ORDER BY table_schema, table_name;
This will generate the SQL statements for all 100 tables at once. You can then:
1. Copy the output
2. Review it carefully
3. Execute all statements in one go
Important notes âĸ â ī¸ Back up your data before running any DDL changes
âĸ â ī¸ Only drop the clustering key if _AIRBYTE_EMITTED_AT is the only clustering key â if other columns are also part of the clustering key, adjust accordingly
âĸ â
After fixing all tables, reset and re-sync your connections in Airbyte UI
âĸ â
Upgrade your Snowflake destination connector to the latest version to prevent this from recurring [Snowflake Destination] đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 6:59 PMkapa.ai
08/04/2026, 6:59 PMCLUSTER BY () syntax details. However, based on the context from the forum post that resolved this issue:
No â leave the brackets empty () The empty brackets () is the correct syntax to remove/drop the clustering key entirely from the table. [Forum Post]
-- This removes the clustering key entirely
ALTER TABLE <your_schema>.<your_table> CLUSTER BY ();
-- Then drop the column
ALTER TABLE <your_schema>.<your_table> DROP COLUMN "_AIRBYTE_EMITTED_AT";
When would you put something in the brackets? You would only put column names inside the brackets if you want to set a new clustering key, for example:
-- Setting a new clustering key
ALTER TABLE <your_schema>.<your_table> CLUSTER BY (some_other_column);
But in your case, since you just want to remove _AIRBYTE_EMITTED_AT as a clustering key so Airbyte can drop it, leaving the brackets empty is the correct approach.
Recommendation I'd suggest verifying this syntax directly in the Snowflake documentation on ALTER TABLE to confirm, as the knowledge sources don't contain the full Snowflake DDL reference. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 7:44 PMkapa.ai
08/04/2026, 7:45 PM_SCD tables:
Why some _SCD tables have data and others don't 1. Basic Normalization was not selected for some tables
The _SCD (history) table is only created and populated when Basic Normalization is enabled. If custom transformation was used instead, the _SCD table may be created but remain empty. [Forum Post]
> When the data was synced, the sync process did not create intermediate table i.e, history table which ends with _SCD. Is it mandatory to select Basic Normalization?
2. Tables without primary keys won't populate _SCD tables
Tables that don't have a primary key defined cannot be loaded incrementally with deduplication, which means the _SCD table may not be populated. [Forum Post]
> The source table needs to have a primary key to be loaded incrementally, because it's using the table primary key for downstream duplication if Incremental - Deduped history is enabled.
3. _SCD tables were removed in Destinations V2
Since you are using a newer version of the Snowflake destination connector, _SCD tables are no longer supported in Destinations V2. [Incremental Append Deduped]
> Previous versions of Airbyte destinations supported SCD tables, which would store every entry seen for a record. This was removed with Destinations V2 and Typing and Deduplication.
Bottom line The _SCD tables with data are likely leftover from a previous pre-Destinations V2 sync, while the empty ones were created under Destinations V2 where SCD tables are no longer populated. This is consistent with your earlier issue where some tables had _AIRBYTE_EMITTED_AT (old) and others didn't (new). đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 7:51 PM_AIRBYTE_EMITTED_AT , right?kapa.ai
08/04/2026, 7:51 PM_AIRBYTE_EMITTED_AT should be safe because:
Why it's safe to drop 1. It's a deprecated legacy field
_AIRBYTE_EMITTED_AT is a pre-Destinations V2 field that has already been replaced by _airbyte_extracted_at in the current Destinations V2. [Airbyte Metadata Fields]
> _airbyte_emitted_at and _airbyte_extracted_at are exactly the same, only the column name changed.
2. Airbyte is already trying to drop it automatically
The error you are seeing (Cannot drop column '_AIRBYTE_EMITTED_AT' which belongs to a clustering key) means Airbyte itself is already attempting to drop this column during schema evolution â it just can't because of the clustering key. [Snowflake PR]
3. The fix specifically removes DROP logic
The latest Snowflake destination connector (4.0.47+) removes the DROP logic entirely, meaning Airbyte will retain old columns instead of dropping them going forward. [Snowflake PR]
Correct order of operations -- Step 1: Remove clustering key FIRST
ALTER TABLE <your_schema>.<your_table> CLUSTER BY ();
-- Step 2: Then drop the column
ALTER TABLE <your_schema>.<your_table> DROP COLUMN "_AIRBYTE_EMITTED_AT";
â ī¸ One caution If you have any downstream models, dashboards, or dbt transformations that reference _AIRBYTE_EMITTED_AT, those will break after dropping the column. Replace any references with _airbyte_extracted_at instead. [Upgrading to Destinations V2]
> You can replace all instances of _airbyte_emitted_at with _airbyte_extracted_at. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 8:35 PMkapa.ai
08/04/2026, 8:35 PM_airbyte_raw_* tables specifically. However, based on what the knowledge sources tell us:
Raw tables are managed by Airbyte internally _airbyte_raw_* tables are internal staging tables managed by Airbyte and are not intended to be modified directly. [Upgrading to Destinations V2]
> We may make further changes to raw tables in the future, as these tables are intended to be a staging ground for Airbyte to optimize the performance of your syncs. We cannot guarantee the same level of stability as for final tables.
My recommendation Only drop the clustering key if:
âĸ â
The raw table has _AIRBYTE_EMITTED_AT as a clustering key
âĸ â
The sync is failing because of it (as shown in your error logs)
You should NOT need to touch raw tables if:
âĸ â The sync error is only occurring on the final tables
âĸ â The raw tables are not causing any errors
To check if raw tables are affected Run this query to see if raw tables specifically have the clustering key issue:
SELECT
table_schema,
table_name,
column_name
FROM information_schema.columns
WHERE column_name = '_AIRBYTE_EMITTED_AT'
AND table_name LIKE '%airbyte_raw%'
AND table_schema = '<your_schema>'
ORDER BY table_schema, table_name;
If the query returns results and those tables are causing sync errors, then apply the same fix. Otherwise, I'd recommend leaving the raw tables untouched to avoid any unintended side effects. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/04/2026, 8:53 PMkapa.ai
08/04/2026, 8:53 PMCannot drop column '_AIRBYTE_EMITTED_AT' error is gone [Schema Change Management]
3. Verify the sync completes successfully
Check the Timeline tab in your connection and confirm:
4. Verify data in Snowflake
Run this query to confirm the column is gone and data is correct:
SELECT *
FROM information_schema.columns
WHERE column_name = '_AIRBYTE_EMITTED_AT'
AND table_schema = '<your_schema>';
This should return no results if the column was successfully dropped from all tables.
â ī¸ Reminder Don't forget to also set up the heartbeat table fix we discussed earlier to prevent the Heartbeat not progressing issue from recurring on the next sync. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 8:57 PMkapa.ai
08/04/2026, 8:57 PM_AIRBYTE_EMITTED_AT column, I'd recommend:
1. â
Trigger a sync now (without clearing) to test if the error is resolved
2. â
Monitor the logs to confirm no _AIRBYTE_EMITTED_AT errors appear
3. â
Only do a Clear if the sync still fails đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 9:00 PMkapa.ai
08/04/2026, 9:00 PMCannot drop column '_AIRBYTE_EMITTED_AT' error is gone
Why this order matters The knowledge sources do not explicitly cover the exact destination test flow in version 2.1.1, so if you cannot find the Test connection button, it is likely located in your Snowflake destination settings page in the Airbyte UI. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 9:10 PMkapa.ai
08/04/2026, 9:10 PMflush.lsn.source = false in the Debezium configuration. Here is what it means: [Github Issue]
Why Airbyte sets flush.lsn.source = false Airbyte deliberately disables Debezium from automatically flushing the LSN back to Postgres. This is a safety mechanism to prevent data loss: [Github Issue]
> flush.lsn.source = false is needed to prevent situations where the replication slot is advanced and the data fails to be written to the destination, or the final state isn't written to the database correctly.
How Airbyte handles LSN flushing instead Since Debezium is not allowed to flush the LSN, Airbyte handles it manually at the start of the next sync: [Github Issue]
> The LSN is advanced on the startup of the subsequent sync. It seems counterintuitive, but this ensures that the previous job was successful, and the job state was written and then read back successfully.
The flow in simple terms Why this matters for your situation This is directly related to the Heartbeat not progressing issue you saw earlier. Because flush.lsn.source = false, the WAL logs will not be cleared automatically â Airbyte needs at least two successful syncs to advance the replication slot. [Github Issue]
This is also why setting up the heartbeat table is important â it ensures the LSN keeps advancing even when there are no new records to sync. [Postgres Troubleshooting] đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 9:12 PMkapa.ai
08/04/2026, 9:12 PMDELETE /jobs/{jobId} endpoint: [Airbyte API]
DELETE /jobs/{jobId}
â ī¸ Things to keep in mind before cancelling Based on your earlier experience: [Clearing Data]
Recommendation Since you are still in the middle of testing after dropping _AIRBYTE_EMITTED_AT, I would suggest:
1. â
Let the sync run a bit longer to confirm the error is gone
2. â
Only cancel if you see the same Cannot drop column '_AIRBYTE_EMITTED_AT' error appearing again in the logs
3. â
Make sure the heartbeat table is set up before the next sync runs đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 9:13 PMkapa.ai
08/04/2026, 9:13 PMHeartbeat not progressing again
âĸ â ī¸ The confirmed_flush_lsn will keep advancing beyond the saved state LSN
âĸ â ī¸ WAL logs will not be cleared properly
How to disable the connection In Airbyte v2.1.1: [Configuring Connections]
1. Go to Connections in the left navbar
2. Find and click your connection
3. Click Settings
4. Toggle the connection to disabled/paused
This prevents any scheduled syncs from running automatically while you set up the heartbeat table.
Setup checklist before re-enabling Do these steps in order:
This way you avoid the same Heartbeat not progressing issue repeating on the next scheduled sync. [Postgres Troubleshooting] đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 9:16 PMkapa.ai
08/04/2026, 9:17 PMHeartbeat not progressing warnings
2. â ī¸ The warnings were about the CDC heartbeat and LSN flushing â these are non-fatal
3. â The subsequent syncs started failing because the LSN issue accumulated over time without the heartbeat table in place
This is exactly why setting up the heartbeat table is important â it prevents those warnings from eventually turning into hard failures on subsequent syncs. [Postgres Troubleshooting] đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 9:22 PMkapa.ai
08/04/2026, 9:22 PMdocs.airbyte.com/assets/images/sync-progresâĻâž
_AIRBYTE_EMITTED_AT and started a new sync, watch the logs closely for:
1. â
No Cannot drop column '_AIRBYTE_EMITTED_AT' errors
2. â
All streams eventually move from Queued â Syncing â Synced
3. â ī¸ Any Heartbeat not progressing warnings in the logs image đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/04/2026, 9:25 PMkapa.ai
08/04/2026, 9:25 PMCREATE TABLE public.airbyte_heartbeat (
id SERIAL PRIMARY KEY,
timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
text TEXT
);
Step 2: Add it to your publication
ALTER PUBLICATION <publicationName> ADD TABLE public.airbyte_heartbeat;
Step 3: Configure Debezium heartbeat query in Airbyte UI
âĸ Go to Sources â select your Postgres source
âĸ Go to Advanced settings â Update Method
âĸ Under Debezium heartbeat query enter:
INSERT INTO public.airbyte_heartbeat (text) VALUES ('heartbeat')
Step 4: Re-enable the connection and trigger a manual sync
Why this keeps happening without the heartbeat table đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/05/2026, 3:50 PMkapa.ai
08/05/2026, 3:50 PMairbyte_heartbeat table created in Postgres
âĸ â
Table added to publication
âĸ â
Debezium heartbeat query configured in Postgres source
âĸ â
Source connection test passed
âĸ â
_AIRBYTE_EMITTED_AT column dropped from all 100 tables
âĸ âŦ Connection re-enabled
âĸ âŦ Manual sync triggered and confirmed successful
Let me know how the sync goes! [Postgres Troubleshooting] đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/05/2026, 3:54 PMkapa.ai
08/05/2026, 3:54 PMHeartbeat not progressing warnings â heartbeat table is set up
2. â
No Cannot drop column '_AIRBYTE_EMITTED_AT' errors â column dropped from all 100 tables
3. â
LSN will advance properly â Debezium heartbeat query is configured
4. â
WAL logs will be cleared â on the startup of the next subsequent sync [Incremental Append Deduped]
Expected sync flow Previous cancelled sync state
â
Airbyte reads cursor value from last saved state
â
Only fetches records newer than last cursor value
â
Appends new records to Snowflake
â
Deduplicates final table by primary key
â
Saves new cursor state
This should be a much faster and cleaner sync than before! Let me know how it goes. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/05/2026, 3:58 PMkapa.ai
08/05/2026, 3:59 PMairbyte_heartbeat table sequence.
Fix â Grant the missing permissions Run these SQL statements in your Postgres database:
-- Grant usage on the schema
GRANT USAGE ON SCHEMA public TO <airbyte_user>;
-- Grant permissions on the heartbeat table
GRANT INSERT, SELECT, UPDATE, DELETE ON TABLE public.airbyte_heartbeat TO <airbyte_user>;
-- Grant permissions on the sequence (this is what's failing)
GRANT USAGE, SELECT ON SEQUENCE public.airbyte_heartbeat_id_seq TO <airbyte_user>;
Replace <airbyte_user> with your actual Airbyte database user. [Postgres Troubleshooting]
After fixing permissions 1. â
Retest the Postgres source connection
2. â
Trigger a manual sync
3. â
Confirm Could not execute heartbeat action error is gone from logs đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/05/2026, 4:01 PMkapa.ai
08/05/2026, 4:02 PMINSERT and UPDATE is a good start, but based on the error you saw, you also need to grant permissions on the sequence specifically, as that is what was failing:
The sequence permission is still needed The error was:
> permission denied for sequence airbyte_heartbeat_id_seq
This means the INSERT permission alone is not enough because the id column uses SERIAL which relies on a sequence to auto-generate IDs. You need to explicitly grant access to the sequence too:
-- This is the missing permission that caused the error
GRANT USAGE, SELECT ON SEQUENCE public.airbyte_heartbeat_id_seq TO <airbyte_user>;
Full set of permissions needed -- Table permissions
GRANT INSERT, UPDATE, SELECT ON TABLE public.airbyte_heartbeat TO <airbyte_user>;
-- Sequence permission (critical - this was the failing part)
GRANT USAGE, SELECT ON SEQUENCE public.airbyte_heartbeat_id_seq TO <airbyte_user>;
After granting sequence permission 1. â
Retest the Postgres source connection
2. â
Trigger a manual sync
3. â
Confirm Could not execute heartbeat action error is gone from logs
The sync should now proceed without the heartbeat permission error. [Postgres Troubleshooting] đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/05/2026, 4:04 PMairbyte_heartbeat_id_seq first?kapa.ai
08/05/2026, 4:04 PMairbyte_heartbeat_id_seq manually! Here is why:
It was already created automatically When you ran this earlier in Step 1:
CREATE TABLE public.airbyte_heartbeat (
id SERIAL PRIMARY KEY,
timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
text TEXT
);
The SERIAL keyword automatically creates the sequence airbyte_heartbeat_id_seq for you. It is already there â you just need to grant permissions on it. [Postgres Troubleshooting]
Just run the grant statement GRANT USAGE, SELECT ON SEQUENCE public.airbyte_heartbeat_id_seq TO <airbyte_user>;
You can verify it exists by running SELECT sequence_name
FROM information_schema.sequences
WHERE sequence_name = 'airbyte_heartbeat_id_seq';
If it returns a result, the sequence is already there and you just need to grant the permissions. â
đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/05/2026, 4:10 PMkapa.ai
08/05/2026, 4:10 PMSELECT
table_schema,
table_name,
column_name
FROM information_schema.columns
WHERE column_name = '_AIRBYTE_EMITTED_AT'
AND table_schema = '<your_schema>'
ORDER BY table_schema, table_name;
This should return zero results.
2. â ī¸ Verify heartbeat table is added to the publication Confirm the heartbeat table was added correctly:
SELECT * FROM pg_publication_tables
WHERE tablename = 'airbyte_heartbeat';
3. â ī¸ Sequence permission still needs to be granted As we just discussed, make sure you run:
GRANT USAGE, SELECT ON SEQUENCE public.airbyte_heartbeat_id_seq TO <airbyte_user>;
4. â ī¸ Downstream models referencing _AIRBYTE_EMITTED_AT If you have any dbt models, dashboards, or transformations referencing _AIRBYTE_EMITTED_AT, they will break. Replace all references with _airbyte_extracted_at instead. [Upgrading to Destinations V2]
5. â ī¸ Retest the Postgres source after granting sequence permission After granting the sequence permission:
âĸ â
Retest the Postgres source connection
âĸ â
Retest the Snowflake destination connection
âĸ â
Then trigger a manual sync
Full checklist before triggering sync đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/05/2026, 4:13 PMkapa.ai
08/05/2026, 4:13 PMinvalid identifier '_AIRBYTE_RAW_ID' means the _AIRBYTE_RAW_ID meta column is missing from one or more of your Snowflake tables. This happens when upgrading from pre-3.10.0 tables to 4.0.0+ because the SnowflakeAbMetaAndGenIdMigration was removed without replacement. [Snowflake PR]
> Snowflake destination fails when upgrading from pre-3.10.0 tables to Direct Load 4.0.0+ because _AIRBYTE_META and _AIRBYTE_GENERATION_ID columns are missing but the COPY INTO statement references them.
Missing meta columns to check The affected meta columns are: [Airbyte Metadata Fields]
Fix â Add missing meta columns First, identify which tables are missing the column:
SELECT table_name
FROM information_schema.tables t
WHERE table_schema = '<your_schema>'
AND NOT EXISTS (
SELECT 1
FROM information_schema.columns c
WHERE c.table_name = t.table_name
AND c.table_schema = t.table_schema
AND c.column_name = '_AIRBYTE_RAW_ID'
);
Then add the missing columns to affected tables:
-- Add all missing meta columns
ALTER TABLE <your_schema>.<your_table>
ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR,
ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ,
ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT,
ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;
Long term fix The permanent fix is available in destination-snowflake 4.0.45+ which automatically adds missing meta columns on the first sync. [Snowflake PR]
> Missing meta columns are automatically added on first sync.
Updated checklist đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/05/2026, 4:18 PMkapa.ai
08/05/2026, 4:18 PMERROR Error closing resource io.airbyte.container.orchestrator.worker.io.LocalContainerAirbyteDestination@3054cdd3; recording failure but continuing.
What this error means This is a secondary error that occurs as a consequence of the primary error (invalid identifier '_AIRBYTE_RAW_ID'). When the destination connector fails, Airbyte tries to close the destination resource but cannot do so cleanly, resulting in this error. [Github Issue]
> This error typically appears after the root cause error and is not the primary issue itself.
This is not the root cause Looking at the pattern from our earlier discussion, this error has appeared consistently across multiple issues:
What to do Fix the root cause first â the _AIRBYTE_RAW_ID missing column issue we just discussed:
ALTER TABLE <your_schema>.<your_table>
ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR,
ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ,
ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT,
ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;
Once the _AIRBYTE_RAW_ID error is resolved, this Error closing resource error should automatically disappear as well. [Github Issue] đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/05/2026, 4:21 PM_AIRBYTE_META and _AIRBYTE_GENERATION_ID columns are missing but the COPY INTO statement references them, so i don't need to worry about these 2 columns, just to add missing column _AIRBYTE_RAW_IDkapa.ai
08/05/2026, 4:21 PM_AIRBYTE_RAW_ID. Here is why:
All missing meta columns need to be added The PR fix specifically mentions both _AIRBYTE_META and _AIRBYTE_GENERATION_ID as missing columns that cause the COPY INTO failure: [Snowflake PR]
> Snowflake destination fails when upgrading from pre-3.10.0 tables to Direct Load 4.0.0+ because _AIRBYTE_META and _AIRBYTE_GENERATION_ID columns are missing but the COPY INTO statement references them, causing SQL compilation error: invalid identifier '_AIRBYTE_META'.
The COPY INTO statement references ALL meta columns Looking at the expected meta columns for schema mode: [SnowflakeColumnManager]
Recommendation Run the query to check all missing meta columns across your tables first:
SELECT
table_name,
MAX(CASE WHEN column_name = '_AIRBYTE_RAW_ID' THEN 'EXISTS' ELSE 'MISSING' END) AS raw_id,
MAX(CASE WHEN column_name = '_AIRBYTE_EXTRACTED_AT' THEN 'EXISTS' ELSE 'MISSING' END) AS extracted_at,
MAX(CASE WHEN column_name = '_AIRBYTE_META' THEN 'EXISTS' ELSE 'MISSING' END) AS meta,
MAX(CASE WHEN column_name = '_AIRBYTE_GENERATION_ID' THEN 'EXISTS' ELSE 'MISSING' END) AS generation_id
FROM information_schema.columns
WHERE table_schema = '<your_schema>'
AND column_name IN ('_AIRBYTE_RAW_ID', '_AIRBYTE_EXTRACTED_AT', '_AIRBYTE_META', '_AIRBYTE_GENERATION_ID')
GROUP BY table_name
ORDER BY table_name;
Then add all missing columns at once to avoid hitting the same error again on the next sync:
ALTER TABLE <your_schema>.<your_table>
ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR,
ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ,
ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT,
ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;
Adding only _AIRBYTE_RAW_ID risks hitting the same invalid identifier error for _AIRBYTE_META or _AIRBYTE_GENERATION_ID on the very next sync. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/05/2026, 4:28 PMkapa.ai
08/05/2026, 4:28 PMALTER TABLE statements for all affected tables at once:
SELECT
'ALTER TABLE ' || '"' || table_schema || '"."' || table_name || '"' ||
' ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR' ||
', ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ' ||
', ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT' ||
', ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;' AS alter_statement
FROM information_schema.tables
WHERE table_schema = '<your_schema>'
AND table_type = 'BASE TABLE'
AND NOT EXISTS (
SELECT 1
FROM information_schema.columns c
WHERE c.table_name = tables.table_name
AND c.table_schema = tables.table_schema
AND c.column_name = '_AIRBYTE_RAW_ID'
)
ORDER BY table_name;
What this does Then execute all generated statements 1. â
Copy the output from the query
2. â
Paste and run all generated ALTER TABLE statements at once
3. â
Verify with the check query from earlier to confirm all columns are present
This way you handle all 60 tables in one shot without manually writing each statement. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/05/2026, 4:40 PMalter table statement and got an error: SQL compilation error: syntax error line 3919 at position 85 unexpected 'COLUMN'. syntax error line 1 at position 99 unexpected 'EXISTS'. syntax error line 1 at position 148 unexpected 'COLUMN'. syntax error line 1 at position 162 unexpected 'EXISTS'. syntax error line 1 at position 198 unexpected 'COLUMN'. syntax error line 1 at position 212 unexpected 'EXISTS'.kapa.ai
08/05/2026, 4:40 PMADD COLUMN IF NOT EXISTS in a single ALTER TABLE statement. You need to use separate ALTER TABLE statements for each column.
Fix â Use separate statements per column ALTER TABLE "<your_schema>"."<your_table>" ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR;
ALTER TABLE "<your_schema>"."<your_table>" ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ;
ALTER TABLE "<your_schema>"."<your_table>" ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT;
ALTER TABLE "<your_schema>"."<your_table>" ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;
Updated auto-generate query for all 60 tables Use this query to generate separate statements for each column per table:
SELECT
'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR;' || chr(10) ||
'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ;' || chr(10) ||
'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT;' || chr(10) ||
'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;' AS alter_statements
FROM information_schema.tables
WHERE table_schema = '<your_schema>'
AND table_type = 'BASE TABLE'
AND NOT EXISTS (
SELECT 1
FROM information_schema.columns c
WHERE c.table_name = tables.table_name
AND c.table_schema = tables.table_schema
AND c.column_name = '_AIRBYTE_RAW_ID'
)
ORDER BY table_name;
Steps 1. â
Run the query above to generate all statements
2. â
Copy the output and run all generated statements at once
3. â
Verify all columns are added with the check query from earlier
This follows the same SQL pattern used in the Snowflake destination fix. [Snowflake PR] đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.Micky
08/05/2026, 4:53 PMkapa.ai
08/05/2026, 4:53 PM_SCD tables in relation to this issue. However, based on what we know:
About _SCD tables _SCD (Slowly Changing Dimension) tables are legacy tables created by older versions of Airbyte's normalization process. In newer versions of Airbyte (Destinations V2), SCD tables are no longer used. [Upgrading to Destinations V2]
My recommendation â ī¸ I would not recommend adding meta columns to _SCD tables because:
What to do instead 1. â
Only add meta columns to the 60 non-SCD tables using the auto-generate query from earlier
2. â
Modify the query to exclude _SCD tables:
SELECT
'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_RAW_ID" VARCHAR;' || chr(10) ||
'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_EXTRACTED_AT" TIMESTAMP_TZ;' || chr(10) ||
'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_META" VARIANT;' || chr(10) ||
'ALTER TABLE "' || table_schema || '"."' || table_name || '" ADD COLUMN IF NOT EXISTS "_AIRBYTE_GENERATION_ID" NUMBER;' AS alter_statements
FROM information_schema.tables
WHERE table_schema = '<your_schema>'
AND table_type = 'BASE TABLE'
AND table_name NOT LIKE '%_SCD'
AND NOT EXISTS (
SELECT 1
FROM information_schema.columns c
WHERE c.table_name = tables.table_name
AND c.table_schema = tables.table_schema
AND c.column_name = '_AIRBYTE_RAW_ID'
)
ORDER BY table_name;
However, I would strongly suggest confirming with Airbyte support whether _SCD tables need to be handled differently in your specific upgrade path, as the knowledge sources do not explicitly cover this scenario. đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elementsMicky
08/06/2026, 4:54 PMkapa.ai
08/06/2026, 4:54 PM_airbyte_extracted_at instead of _airbyte_emitted_at
4. â
_SCD tables â monitor if they cause any issues in future syncs
Great job working through all those issues! Let me know if you run into anything else. đ đ 0 button đ 0 button âšī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements