DataGrip Schema Synchronization Missing Exclusive Metadata Lock Option

Short answer

No. DataGrip does not provide a supported setting to prepend an explicit LOCK TABLES, pg_advisory_xact_lock or equivalent metadata lock before a Schema Synchronization script, and there is no hidden toggle under Tools → Database → Data Extractors and Synchronization → Options to enable automatic metadata lock acquisition.

Confirmed facts

• The Schema Synchronization wizard generates DDL with vendor-specific online hints, e.g., MySQL ALGORITHM=INPLACE and PostgreSQL CONCURRENTLY, and can wrap the script in BEGIN/COMMIT via the "Wrap in transaction" option.
• The Options dialog for Data Extractors and Synchronization controls script formatting, transaction wrapping, and DDL hint inclusion. It does not expose any option for pre-script lock statements or automatic metadata lock acquisition.
• DataGrip does not detect or warn about concurrent DDL locks held by other sessions at generation or execution time. Lock contention is a database-runtime concern, not a DataGrip check.
• Transaction wrapping groups statements atomically; it does not acquire an exclusive metadata lock ahead of DDL. Metadata locks are acquired implicitly per statement by the database engine.

Likely explanation

DataGrip is a schema design and DDL generation tool. Lock orchestration and serialization are deliberately left to the database engine and to deployment tooling. Adding an IDE-level lock would be engine-specific, risk breaking transactional semantics, and would not prevent a concurrent session from starting DDL after the lock is released.

Production verification steps for this case

1. Inspect the generated script. Generate a test synchronization for a non-production schema and confirm the output contains only DDL with hints, no LOCK TABLES or advisory lock calls.
2. Do not rely on online DDL hints alone. Test the script in a staging environment that mirrors production isolation and workload. Simulate concurrent DDL on the same objects while the script runs to observe blocking or wait behavior.
3. Use database-native lock monitoring during the test: MySQL SHOW ENGINE INNODB STATUS and performance_schema.metadata_locks, PostgreSQL pg_locks and pg_stat_activity, SQL Server sys.dm_tran_locks. This shows actual metadata lock waits.
4. If a guardrail is required, add it outside DataGrip. Prepend a manual advisory lock in your deployment pipeline, e.g., SELECT pg_advisory_xact_lock(id) for PostgreSQL, or use a maintenance window / blue-green deployment. DataGrip scripts can be edited before execution.

To give a precise recommendation for a safe deployment pattern, what database engine and DataGrip build are you using? The available native locking primitives and the exact Options UI differ by engine and version.