ALTER TABLE … ADD PRIMARY KEY defines a non-enforced uniqueness constraint on one or more columns.
BigQuery now lets you declare PRIMARY KEY constraints to signal that rows are unique. Though NOT ENFORCED, the flag improves data modeling, downstream tool compatibility, and query documentation.
Use ALTER TABLE table_name ADD CONSTRAINT constraint_name PRIMARY KEY(column_list) NOT ENFORCED; The NOT ENFORCED clause is mandatory today.
Run ALTER TABLE Customers ADD CONSTRAINT pk_customers PRIMARY KEY(id) NOT ENFORCED; This tells BigQuery each id in Customers is unique.
Yes. CREATE TABLE Orders(id INT64, customer_id INT64, order_date DATE, total_amount NUMERIC, CONSTRAINT pk_orders PRIMARY KEY(id) NOT ENFORCED); declares the key at creation time.
List multiple columns. Example: ALTER TABLE OrderItems ADD CONSTRAINT pk_orderitems PRIMARY KEY(order_id, product_id) NOT ENFORCED; ensures each product appears only once per order.
No. The engine does not prevent duplicates yet. You must manage data quality via ETL checks or query audits.
1) Add keys in staging first to catch issues. 2) Name constraints pk_
. 3) Document composite keys in comments. 4) Periodically verify uniqueness with SELECT COUNT(*) vs COUNT(DISTINCT …).
Use ALTER TABLE Customers DROP CONSTRAINT pk_customers; then add a new one if needed.
Because constraints are not enforced, they do not impact read or write speed. They solely add metadata. Future enforcement may introduce checks.
SELECT id, COUNT(*) FROM Customers GROUP BY id HAVING COUNT(*) > 1; returns duplicates you should fix before trusting the key.
See the syntax and ecommerce example below.
No. The constraint stores minimal metadata and does not duplicate data.
Yes. The syntax is identical. Ensure uniqueness across all partitions.
Google states enforcement may come later. Plan data quality processes now to avoid surprises.