Greetings @yashojha ,
It sounds like your Unity Catalog schema sync is running into legacy Hive Metastore Parquet type handling, not a Databricks Runtime issue per se.
What’s actually happening
That error message — “Parquet does not support date. See HIVE-6384” — isn’t coming from Spark’s native Parquet reader. It’s emitted by the Hive metastore client and SerDe path when a tool tries to introspect table metadata, often during operations like DESCRIBE EXTENDED. Older Hive clients, especially 0.13, simply don’t support DATE, TIMESTAMP, or DECIMAL types in Parquet and will throw this exact error during metadata access.
Historically, Databricks Runtime clusters defaulted to a Hive metastore client version around 0.13.0. That’s why you can see a table read cleanly in a notebook but fail during schema syncs or DBSQL operations. The notebook path uses Spark’s reader, while DBSQL and similar tooling rely on Hive SerDe for table description.
This shows up a lot in DBSQL and SQL Warehouses. The same table can work perfectly in a Spark notebook yet fail in DBSQL, simply because the warehouse is using a different Hive client and hits the legacy SerDe code path during metadata calls.
Ways to fix it
Which path you choose depends on where the schema sync is actually running. Most UC sync and assessment workflows invoke DBSQL under the hood.
If the sync is using a SQL Warehouse, configure that warehouse to use a newer Hive metastore client. In the warehouse’s Data Access configuration, set:
spark.sql.hive.metastore.version = 2.3.3
spark.sql.hive.metastore.jars = maven
Restart the warehouse and rerun the sync. This configuration has consistently eliminated HIVE-6384 errors related to DATE, TIMESTAMP, and DECIMAL during DBSQL describe and introspection flows.
If the sync is running from an interactive cluster, make sure the cluster is using a Hive client version that supports those Parquet types. For DBR 7.x and newer, that usually means pointing spark.sql.hive.metastore.jars to downloaded jars and setting spark.sql.hive.metastore.version to 1.2.1 or higher, or using the Maven option where supported. A restart is required before retrying the sync.
If you’re dealing with Hive SerDe Parquet tables that still fail, the pragmatic solution is to migrate them to Delta before upgrading. Many HMS SerDe tables aren’t eligible for in-place upgrade and require a data copy. That’s why UCX assessments often flag assets as “Asset Replication Required” or explicitly note that tables are being ignored due to HIVE-6384.
A straightforward approach is a CTAS into Unity Catalog, for example:
CREATE TABLE uc_catalog.target_db.my_table
USING DELTA
AS SELECT *
FROM hive_metastore.source_db.my_table;
Once that’s done, register and use the Delta table in UC instead of the original Hive SerDe Parquet table for the sync.
Why changing DBR didn’t help
Lowering or changing the Databricks Runtime version doesn’t address this class of failure because the error occurs during Hive metadata access. That path depends on the Hive client and JARs used by the SQL Warehouse or whichever process is doing the introspection, not the DBR on your interactive cluster. Adjusting the warehouse’s Hive configuration is the reliable fix.
A quick way to confirm
From the same SQL Warehouse used for the sync, try running:
DESCRIBE EXTENDED hive_metastore.db.table_with_date;
If that fails with HIVE-6384, you’re definitely hitting the legacy Hive SerDe path and need the warehouse configuration changes above.
Bottom line recommendation
First, identify which SQL Warehouse your UC sync or assessment is using.
Second, set spark.sql.hive.metastore.version to 2.3.3 and spark.sql.hive.metastore.jars to maven on that warehouse, restart it, and rerun the sync.
If specific Hive SerDe Parquet tables still fail, CTAS them to Delta in Unity Catalog and proceed with the upgrade using those Delta assets.
If you can confirm whether the sync is running through a specific SQL Warehouse (and share its ID) or an interactive cluster, and optionally paste the DDL for one of the failing tables, I can give you a very targeted CTAS-to-Delta recommendation.
Regards, Louis.
