Did a BigQuery query come back and then fall over inside Pandas?
pd.Series([], dtype='dbdate')
TypeError: data type 'dbdate' not understood
dbdate is not a Pandas dtype. It comes from db-dtypes, a small package that Google's BigQuery client uses to represent SQL DATE and TIME columns, which have no exact Pandas equivalent. When that package is missing, something asks Pandas for a dtype it has never heard of, and this is what you get.
The fix is usually one install:
uv add db-dtypes
or pip install db-dtypes if you are not using uv. Then restart the kernel, because the dtype has to be registered before the frame is built.
Why it surfaces so far from the cause
The confusing part is where the error appears. Nothing in your code mentions dbdate. You ran a query, got a data frame, and then a later line — a to_parquet, a concat, a pickle load — raised a TypeError about a type you have never typed.
That is because the dtype name travels with the data. A saved frame, a cached parquet file or a pickle records that a column is dbdate, and reading it back asks Pandas to reconstruct that dtype. On a machine where db-dtypes is installed it reconstructs fine. On a colleague's machine, or in CI, or in a container built from a slimmer requirements file, it does not.
So if this appears in a place that never touches BigQuery, look at where the data was created rather than where it broke.
If you would rather not add the dependency
You can convert the columns away from dbdate at the boundary, right after the query, and keep everything downstream in plain Pandas types:
df['order_date'] = pd.to_datetime(df['order_date'])
dbdate becomes datetime64, dbtime becomes a timedelta or a string depending on what you need, and nothing you save afterwards carries a dtype that needs an extra package to read. That is worth doing on purpose if the frame is going to be written to disk and read by other people.
The trade-off is real: dbdate exists because SQL DATE has no time component and datetime64 does, so converting adds a midnight that was never in the database. For most analysis that does not matter. For anything that round-trips back into BigQuery, it can.
Checking what you actually have
When a frame arrives from a database client, the dtypes are the first thing worth looking at:
df.dtypes
Anything that is not a familiar Pandas dtype came from a package, and that package is now a requirement for reading your saved output. Writing it down beside the data saves the next person the search that brought you here.
The mistakes I see most often
Installing the package but not restarting. The dtype registry is read at import time. An install in one cell and a retry in the next, without a restart, fails identically.
Adding it to the wrong environment. A notebook kernel and a terminal are often two different environments. import db_dtypes in the same kernel that raised the error is the check that settles it.
Pinning it out of a container. This error turning up only in CI almost always means the deployment requirements were trimmed to what the code imports by name, and nothing imports db-dtypes explicitly — the BigQuery client asks for it at runtime.
Practice
See to_datetime in Pandas for converting date columns, and read_parquet in Pandas for what survives a round trip to disk.