Is dbdev still solving a problem? If so, what problem is it solving?
I maintain https://github.com/point-source/supabase-tenant-rbac, a package distributed via database.dev. I've been working through several user-reported issues that all trace back to the same root cause: objects created via CREATE EXTENSION are registered as extension members in pg_depend, which causes standard PostgreSQL tooling to skip them.
These aren't edge cases, they're core local development and operational workflows. See https://github.com/point-source/supabase-tenant-rbac/issues/23 and https://github.com/point-source/supabase-tenant-rbac/issues/41 on my repo for real user impact.
With the deprecated in-database client, there was a clear reason for pg_tle: users ran dbdev.install(...) directly in their database, so TLE was the delivery mechanism. But now that the recommended workflow is dbdev add, which generates a migration file, the TLE layer sits between the user and what they actually need, which is plain SQL objects in their database. Why are we using a cli tool to generate migration files that pretty much just take normal migration files and wrap them in a pg_tle extension?
Both flows end with a migration file. The only difference is whether the SQL inside is wrapped in TLE or not. The TLE wrapping is what causes the tooling breakage.
Could dbdev add have an option (or even a new default) to generate plain SQL migrations instead of TLE-wrapped ones? The CLI already fetches the package SQL from the registry — it would just need to resolve @extschema@ to the target schema and emit the raw DDL.
The registry, CLI, and versioning model all remain valuable. It's specifically the TLE install mechanism in the generated migration that causes problems.
For upgrades, dbdev upgrade could generate a migration containing only the diff (ALTER/CREATE OR REPLACE statements), which is what package authors already write as upgrade path scripts.
Am I missing something?
The user questions the necessity of the TLE layer in the current dbdev workflow, which generates migration files. They highlight issues with standard PostgreSQL tooling that skips extension member objects, causing problems with pg_dump, supabase db diff, and migration squashing. They propose generating plain SQL migrations instead of TLE-wrapped ones to resolve these issues.
Thanks for starting this discussion @point-source. You raise some valid points. We are re-evaluating whether pg_tle is really required and having internal discussion about this.