A star schema keeps dimensions denormalized, while a snowflake schema normalizes them into sub-tables—affecting query speed, storage, and maintenance in PostgreSQL.
A star schema stores one central fact table and several denormalized dimension tables. Each dimension sits "close" to the fact table, minimizing joins and boosting query speed.
A snowflake schema normalizes dimension tables into multiple related sub-tables.This reduces redundancy and storage but increases join depth during queries.
Choose star when read performance is critical, dimensions change infrequently, and disk space is not a major constraint.
Use snowflake when dimension data is large, highly repetitive, or frequently updated—saving space and easing maintenance.
-- Fact table
CREATE TABLE Orders (
id SERIAL PRIMARY KEY,
customer_id INT,
order_date DATE,
total_amount NUMERIC(12,2)
);
-- Denormalized dimension
CREATE TABLE Customers (
id INT PRIMARY KEY,
name TEXT,
email TEXT,
created_at TIMESTAMP
);
-- Dimension split into sub-tables
CREATE TABLE CustomerCore (
id INT PRIMARY KEY,
name TEXT
);
CREATE TABLE CustomerContact (
customer_id INT REFERENCES CustomerCore(id),
email TEXT,
created_at TIMESTAMP
);
Star schemas need fewer joins: FROM Orders JOIN Customers USING (id)
.Snowflake schemas add hops: Orders → CustomerCore → CustomerContact
.
Benchmark both designs with representative workloads. Add indexes on foreign keys. Avoid partial snowflakes; stay consistent.
See dedicated section below.
.
Yes for read-heavy workloads, because it reduces joins. However, updates can be slower due to redundancy.
For large, repetitive dimensions, splitting tables can cut storage by 30-70%.
Yes—normalize dimensions and update foreign keys. Migrate during low-traffic windows.