The Netflix sample database is a learning database based on public data from Netflix’s Engagement Report and Global Top 10 lists. This guide walks you through installing it on PostgreSQL.
For more background on this database, see my introduction to the Netflix Sample Database.
JSON has become a common format for data exchange, and SQL Server’s built-in JSON support makes it straightforward to work with JSON data directly in your queries. But what happens when you need to pivot JSON data – transforming nested structures or array elements into a columnar format for reporting or analysis?
SQL Server provides functions like OPENJSON(), JSON_VALUE(), and JSON_QUERY() that let you extract and manipulate JSON data. Combined with standard pivoting techniques, you can reshape JSON data into whatever format you need. This can be particularly useful when you’re receiving JSON from APIs, storing semi-structured data, or working with configuration data that doesn’t fit neatly into traditional tables.
SQL Server provides a solid set of system data types that handle everything from storing tiny integers to massive text blobs. Understanding these types is an important part of designing efficient databases, mainly because picking the right data type can save storage space and improve query performance.
This article breaks down all the data types available in SQL Server (as of SQL Server 2025), organized by category. Each type includes its max length, precision, scale, and whether it can be nullable.
If you’re getting an error in SQL Server that reads something like “ALTER TABLE only allows columns to be added that can contain nulls, or have a DEFAULT definition specified, or the column being added is an identity or timestamp column, or… etc etc“, it’s probably because you’re trying to add a NOT NULL column to a table that already contains data.
This error occurs due to the fact that the NOT NULL constraint will be violated for every row in the table. Think about it for a second. When you first add the column, there’s no data. It’s not until you run a subsequent INSERT statement (or some other process that populates the table) that you will get data. In the meantime, all values in your new column will be NULL. And that, of course, violates the NOT NULL constraint.
When you’re designing a relational database, you need to define how tables relate to each other. You do this by creating relationships between the tables. Relationship cardinality describes how many records in one table can be associated with records in another table. It’s a fundamental concept that affects how you structure your database and write your queries.
Understanding cardinality helps you avoid design mistakes that lead to data integrity issues, performance problems, or queries that return unexpected results.
SQL Server’s Query Store can accumulate hundreds or even thousands of queries over time. When troubleshooting a specific performance issue or investigating a particular query, you’ll probably want to search the captured data to find what you’re looking for.
A vector database is a specialized database designed to store, index, and query high-dimensional vectors. These are arrays of numbers that represent data in mathematical space. Unlike traditional databases that store text, numbers, or structured data, vector databases work with embeddings, which are numerical representations of complex data like text, images, audio, or video that capture their semantic meaning.
These databases solve the specific problem of finding similar items based on meaning rather than exact matches. Traditional databases excel at finding exact matches or simple comparisons. For example “find all users named Bella” or “find products under $50.” Vector databases excel at similarity searches. These could look something like “find images similar to this one” or “find documents with similar meaning to this query,” even when the exact words or pixels are different.
SQL Server’s Query Store operates independently on each database and can be in different states depending on its configuration and current storage usage. Checking the status helps you verify that Query Store is working as expected and identify any issues that might prevent data collection.
While SQL Server’s DATEDIFF() function is relatively straightforward when you’re comparing two known dates, it becomes more flexible when the dates you compare are sourced directly from your tables. Instead of hardcoding dates, you can embed subqueries directly into the DATEDIFF() function to dynamically retrieve the dates you need.
This approach can be especially useful when you’re working with aggregate functions like MIN() and MAX(), or when you need to pull specific dates based on certain conditions. The subqueries execute first, return their date values, and DATEDIFF() uses those results to perform the calculation.