You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Can't use SDL or Sync Schema due to "does not exist" errors #20434
Hi everyone, I'm trying out ByteBase and I've encountered some problems. Hope we can fix them.
Whenever I'm trying to use SDL or Sync Schema I get an error like these:
(Sync Schema) ERROR: type "public.type_my_custom_type" does not exist (SQLSTATE 42704)
failed to compute SDL migration: failed to load source schema: ERROR: type "type_billing_current_settlement" does not exist (SQLSTATE 42704)
failed to compute SDL migration: failed to load target schema: ERROR: schema "metric_helpers" does not exist (SQLSTATE 3F000)
pretty sure I got one about a Function too after trying to delete all custom types.
At first the Export Multi-File didn't export any custom types, but then again I added them manually for testing and still got the same error. Same for schemas, it existed for sure in both databases, but still got the error.
Tried with my custom Database to Code folder too, same error.
I made sure I synched each database before trying again.
Steps to reproduce
Setup bytebase via Docker Desktop.
Connect to my local DB server with multiple DBs.
Set a docker container with a GitLab runner (shell enviroment).
Use all necessary connections, vars and configs to make SDL work via bytebase-action.
Export Schema > Multi-FIle (ZIP) from my main and up-to-date database.
Setup a repo with the so-called Schema.
Run an SDL with --declarative.
Go to ByteBase UI > My Project > Plan
See the plan it has made.
Try Deploying.
Get error.
Tried with Sync Schema via the ByteBase UI (transfering one database DDL to another), same errors.
At this point I don't know what to do, I've tested with multiple database backups, even an empty one with only schemas created. Still errors, no results.
changed the title [-]Can't use SDL or Sync Schema due to "missing" errors[/-][+]Can't use SDL or Sync Schema due to "does not exist" errors[/+]on May 28, 2026
Hi @chriskovaios , thank you for reporting this issue.
The SDL feature currently requires us to include all schema and files from the exported schema on database page (artifact from your step 5) included in the git repo setup for SDL.
If we have already done so, and still running into issue. Would you please share a copy of your schema files?
I've made a simple example with a brand new database, using the same schema structure. You can test it yourself. (I've first built it in my postgres client like pgadmin4, connected and exported the database from Bytebase Multi-File (zip) and then run the SDL via the gitlab-runner using bytebase-action --declarative)
Since then I've noticed that there's a list of "Limitations" on this README.md of bytebase-action it doesn't include "CREATE TYPE" statements, so I guess there's nothing wrong on my end and it's just not the right tool for my use case.
I've tried dropping all Types (and some sequences that caused problems like rr_pending_changes) and it seems to be at least working, but I can't afford such a huge change for just one tool.
Thanks for the detailed repro, @chriskovaios — your diagnosis is correct. The blocker is PostgreSQL composite types (CREATE TYPE ... AS (...)), like the TYPE_GET_PRODUCT / TYPE_LIST_PRODUCTS in your example.
Bytebase currently models enum types but not composite types, so they aren't captured during sync and aren't emitted by Export / Sync Schema. The functions that return those types are captured, so the reconstructed schema references a type that was never defined — which is the type "..." does not exist (SQLSTATE 42704) you're seeing. That's also why adding the types back into the files by hand didn't help: the failure is on Bytebase's side of the comparison (its synced copy of your live schema), not your files.
This is a real gap, not something on your end. We've converted this into a feature request to add composite-type support to PostgreSQL schema sync and SDL, and we're tracking it internally. For now, schemas that rely on composite types aren't fully supported by SDL / Sync Schema.
Thanks again for taking the time to put together a clean reproduction — it made this easy to pin down.
Both errors are addressed. The type ... does not exist (42704) failures came from Bytebase not modeling PostgreSQL composite types — that's now fully supported (sync, schema export, SDL, and Sync Schema) via #20911/#20912/#20913 and will be in the 3.21.0 (July 30, 2026). The schema "metric_helpers" does not exist (3F000) error was a separate bug where multi-file exports didn't emit CREATE SCHEMA for non-public schemas — that was fixed in #20530 and already shipped in 3.19.1, so upgrading from v3.18.0 resolves it. We've verified both workflows end-to-end against a schema like yours (custom composite types plus a metric_helpers schema); if you still hit errors after upgrading, please share the statement and we'll dig in.
Activity
[-]Can't use SDL or Sync Schema due to "missing" errors[/-][+]Can't use SDL or Sync Schema due to "does not exist" errors[/+]zchpeter commentedon Jun 4, 2026
Hi @chriskovaios , thank you for reporting this issue.
The SDL feature currently requires us to include all schema and files from the exported schema on database page (artifact from your step 5) included in the git repo setup for SDL.
If we have already done so, and still running into issue. Would you please share a copy of your schema files?
chriskovaios commentedon Jun 8, 2026
I've made a simple example with a brand new database, using the same schema structure. You can test it yourself. (I've first built it in my postgres client like pgadmin4, connected and exported the database from Bytebase Multi-File (zip) and then run the SDL via the gitlab-runner using bytebase-action --declarative)
test_database.sql
Since then I've noticed that there's a list of "Limitations" on this README.md of bytebase-action it doesn't include "CREATE TYPE" statements, so I guess there's nothing wrong on my end and it's just not the right tool for my use case.
I've tried dropping all Types (and some sequences that caused problems like rr_pending_changes) and it seems to be at least working, but I can't afford such a huge change for just one tool.
d-bytebase commentedon Jun 9, 2026
Thanks for the detailed repro, @chriskovaios — your diagnosis is correct. The blocker is PostgreSQL composite types (
CREATE TYPE ... AS (...)), like theTYPE_GET_PRODUCT/TYPE_LIST_PRODUCTSin your example.Bytebase currently models enum types but not composite types, so they aren't captured during sync and aren't emitted by Export / Sync Schema. The functions that return those types are captured, so the reconstructed schema references a type that was never defined — which is the
type "..." does not exist (SQLSTATE 42704)you're seeing. That's also why adding the types back into the files by hand didn't help: the failure is on Bytebase's side of the comparison (its synced copy of your live schema), not your files.This is a real gap, not something on your end. We've converted this into a feature request to add composite-type support to PostgreSQL schema sync and SDL, and we're tracking it internally. For now, schemas that rely on composite types aren't fully supported by SDL / Sync Schema.
Thanks again for taking the time to put together a clean reproduction — it made this easy to pin down.
feat(pg): support composite types in schema sync and SDL dump
feat(pg): support composite types in schema sync and SDL dump (#20911)
h3n4l commentedon Jul 16, 2026
Both errors are addressed. The type ... does not exist (42704) failures came from Bytebase not modeling PostgreSQL composite types — that's now fully supported (sync, schema export, SDL, and Sync Schema) via #20911/#20912/#20913 and will be in the 3.21.0 (July 30, 2026). The schema "metric_helpers" does not exist (3F000) error was a separate bug where multi-file exports didn't emit CREATE SCHEMA for non-public schemas — that was fixed in #20530 and already shipped in 3.19.1, so upgrading from v3.18.0 resolves it. We've verified both workflows end-to-end against a schema like yours (custom composite types plus a metric_helpers schema); if you still hit errors after upgrading, please share the statement and we'll dig in.