Beyond Start and End columns with PostgreSQL range types

One of the most read articles at boringSQL is Time to Better Know The Time in PostgreSQL where we dived into the complexities of storing and handling time operations in PostgreSQL. While the article introduced the range data types, there’s so much more to them. And not only for handling time ranges. In this article we will cover why to consider range types and how to work with them.

Bug Not Invented Here

But before we can talk about the range types, let’s try to understand why we should look at them in the first place. Let’s imagine a booking platform for large flash sales of the seats, that goes live at 10pm and will be taken by storm by thousands of people who want to get their tickets.

CREATE TABLE seat_holds (
hold_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,

seat_id INTEGER NOT NULL REFERENCES seats(id),
user_session_id UUID NOT NULL,
-- define the hold period explicitly
hold_started_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
hold_expires_at TIMESTAMPTZ NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX seat_holds_on_seat_id ON seat_holds(seat_id);
CREATE INDEX seat_holds_on_expiration ON seat_holds(hold_expires_at);

While the table design looks perfectly reasonable, it has one serious flaw - there’s no database-level atomicity guarantee there to prevent two holds for the same seat_id at the same time. The table design requires on application logic to check for the existing holds before inserting a new hold, and at the same time it does not provide any high-concurrency guarantee.

If all you have in your toolbelt are those two columns you will end up increasing the complexity to make it work. You started with one problem and soon your application developers might want to ask you to add caching layer (most likely external K/V store) to place the holds there and very soon you have N-problems when you will resort to building a complex, custom application-side locking mechanism that is bug-prone and difficult to maintain.

Other possibility is to bring all the operations on seat holds into more complex transaction management. Which is literally invitation for disaster in extreme contention situation like flash ticket sales. No matter which blocking strategy you use SERIALIZABLE transaction isoliation or pessimistic locking using SELECT ... FOR UPDATE will create a large overhead in application logic (retries, massive contention on database resources, etc.).

And as we are going to talk about range data types, there’s a first possible option to solve the problem directly on database level.

-- needed to add GiST support to equality of integers (for seat_id)
CREATE EXTENSION IF NOT EXISTS btree_gist;

ALTER TABLE seat_holds ADD CONSTRAINT seat_holds_no_overlap
EXCLUDE USING gist (
seat_id WITH =,
tsrange(hold_started_at, hold_expires_at) WITH &&
);

Which will add the constraint directly on the table level and enable atomic conflict detection for your seat holds with minimum locking overhead. This guarantees that the database will never allow two overlapping holds to exist for the same seat, irrespective of how many concurrent users are attempting to book. The real win here is data integrity - you’re making it impossible to have invalid state in your database, not just unlikely. While you’ll still need retry logic in your application when conflicts occur, you’ve moved the correctness guarantee from application code (where bugs hide) into the database schema (where it’s enforced). The GiST (Generalized Search Tree) index is the crucial component which makes checking for overlapping time ranges effective even under extreme load.

But really, if you look at the proposed fix, it’s still a workaround - we’re converting two separate TIMESTAMPTZ columns into a range type on the fly, when range types already include native GiST support out of the box.

Introducing the Data Range Types

You’ve seen the power of the EXCLUDE constraint to solve the concurrency problem, but why to settle for workaround (unless it’s temporary as part of the bigger refactoring) instead of going all the way in?

This brings us to the core of the matter: PostgreSQL’s native Range Types.

PostgreSQL provides a set of built-in range types, all following the pattern of type and range:

• int4range for integer
• int8range for bigint
• numrange for numeric
• tsrange for timestamp without time zone
• tstzrange for timestamp with time zone (which we briefly saw above)
• daterange for date

And it does not stop there. You can easily define your own custom range types over any basic data type.

First win: cleaner schema

When using start and end columns you are not explicitely telling the database that these two columns are single concept representing time span. The logic to work with those two columns resides only in your queries and application code.

When you refactor our sample table to embrace the native range type, it becomes more expressive and inherently correct. The application code no longer needs to manage two separate boundaries.

CREATE TABLE seat_holds_native (
hold_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
seat_id INTEGER NOT NULL REFERENCES seats(id),
user_session_id UUID NOT NULL,
hold_period TSTZRANGE NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

This is the power of a first-class data type. We’ve shifted the burden from the application logic to the database schema, making the table definition itself communicate its intent more clearly.

Second win: Atomicity guaranteed

While the new schema is cleaner, the real database win comes from enforcing our concurrency guarantee - preventing two seats from being double-booked. To achieve this you can reuse the exclusion constraint as demonstrated previously.

ALTER TABLE seat_holds_native ADD CONSTRAINT seat_holds_no_overlap
EXCLUDE USING gist (
seat_id WITH =,
hold_period WITH &&
);

This time you can use hold_period directly without need to explicitely convert it. This constraint enforces two rules at once:

1. seat_id WITH = ensures the constraint only applies to holds for the same seat.
2. hold_period WITH && checking the overlap of hold periods with the operator &&

Finally EXCLUDE USING gist is the crucial technical detail, telling PostgreSQL to use GiST index to enforce the constraint. This is not specific to range types, as EXCLUDE constraint can’t exist without an index to enforce it (common use cases might include arrays, geometric data, etc.).

Range boundaries: A quick math refresher

Before we dive into the operators, let’s take a moment to understand how PostgreSQL represents range boundaries. If you remember your high school math, range types use the same notation as intervals in mathematics.

PostgreSQL ranges can have four different boundary types:

Inclusive boundaries - [ and ] An inclusive boundary includes the endpoint value in the range. Think of it as “less than or equal to” or “greater than or equal to”.

-- [10, 20] includes both 10 and 20
-- represents 10 ≤ x ≤ 20
SELECT int4range(10, 20, '[]');

Exclusive boundaries - ( and ) An exclusive boundary excludes the endpoint value from the range. This is “less than” or “greater than” without the equality.

-- (10, 20) excludes both 10 and 20
-- represents 10 < x < 20
SELECT int4range(10, 20, '()');

Mixed boundaries - [) or (] You can mix and match. The most common and default pattern in PostgreSQL is [) - inclusive lower bound, exclusive upper bound. This is particularly useful for timestamps and dates because it naturally represents “from the start of one period up to (but not including) the start of the next”.

As mentioned, the default boundary [) eliminates the natural ambiguity when representing consecutive periods.

-- these ranges are adjacent, not overlapping
-- Week 1
SELECT '[2025-11-01, 2025-11-08)'::tstzrange;
-- Week 2
SELECT '[2025-11-08, 2025-11-15)'::tstzrange;

With this notation, the end of one period is exactly the start of the next, with no gaps or overlaps. This makes it perfect for time-based ranges, inventory availability windows, or any scenario where you’re dividing a continuum into distinct segments.

Canonicalization and Range Set Operations

Boundaries are not the only aspect of the ranges that behave like mathematical sets, allowing arithmetic operations and canonicalization of the discrete ranges.

For discrete range types (int4range, int8range, daterange), multiple representations can actually mean the exact same set of values. For example, for integers, the range [10, 20] (inclusive on both ends) is the same set as (9, 21) (exclusive on both ends) or the default PostgreSQL canonical form [10, 21) (inclusive lower, exclusive upper).

PostgreSQL uses a canonicalization function to convert all equivalent discrete ranges into a single, uniform representation (default [) boundary mentioned above), which is essential for accurate equality checks and indexing.

-- [10, 20] includes integers 10, 11, ..., 20.
SELECT int4range(10, 20, '[]') AS original_range;
-- Result: [10,21)

-- (9, 21) includes integers 10, 11, ..., 20.
SELECT int4range(9, 21, '()') AS original_range;
-- Result: [10,21)

Exception are continuous ranges (think floats and timestamps with fractional seconds) where PostgreSQL won’t use canonicalization because a boundary change always means a change in the contained values as there’s no easy to define “next value”. I.e. there’s no next value for 20.0 (i.e. not 20.0001, nor 20.000001, etc.) and changing boundary would change it’s meaning.

The operator toolkit

The type ranges and by their definition GiST (in this instance range_ops) and GIN (array_ops) indexes come with number of operator that makes your life easier.

Overlap operator - && As mentioned already above the overlap operator is the most fundamental one. It simply checks whether two ranges share any common data points.

-- find holds active at any point between 10:00 and 11:00
SELECT * FROM seat_holds_native WHERE hold_period && '[2025-12-25 10:00, 2025-12-25 11:00)'::tstzrange;

**Contains operator - `@>`**
For checking against specific moments in time, we might turn to the Contains operator. It verifies whatever the range on the left completely containts the element on the right (which might be both underlying data type or range type).

```sql
-- find holds that are active at the specific momement
SELECT * FROM seat_holds_native WHERE hold_period @> '2025-11-05 15:00'::timestamptz;

-- find holds that are active at the specific time range
SELECT * FROM seat_holds_native WHERE hold_period @> '[2025-12-25 10:00, 2025-12-25 10:15)'::tstzrange;

Contained By operator - <@ In contrast, the Contained By operator checks the reverse relationship - whatever the range on the left is entirely contained by the range on the right.

-- find holds that are within November '25
SELECT * FROM seat_holds_native WHERE hold_period <@ '[2025-11-01, 2025-12-01)'::tstzrange;

Strictly Before/After operators - << and >> operators allow you to query ranges that are completely separated from the reference range (i.e. don’t even touch the boundaries).

-- find holds that finished strictly before 10 November
SELECT * FROM seat_holds_native WHERE hold_period << '[2025-11-10, 2025-11-15)'::tstzrange;

Boundary Extension operators - &< and &> let you reason about range boundaries independently, checking whether one range extends beyond another’s endpoints (i.e. it can start/end anywhere within the given range).

-- find holds that end before or at the same time as reference range ends
SELECT * FROM seat_holds_native WHERE hold_period &< '[2025-11-08 17:00, 2025-11-08 18:00)'::tstzrange;

-- find holds that start at or after reference range starts
SELECT * FROM seat_holds_native WHERE hold_period &>'[2025-11-08 09:00, 2025-11-08 18:00)'::tstzrange;

Finally the Adjecent operator - -|- checks if two ranges are perfectly contiguous - they MUST touch at exactly one boundary point, but do not overlap. This might be invaluable when checking if a customer can extend an existing hold without any gap or conflict.

-- find holds that are immediately adjacent (touching) to given range
SELECT * FROM seat_holds_native WHERE hold_period -|- '[2025-11-08 17:00, 2025-11-08 18:00)'::tstzrange;

To Infinity and Beyond

Similar to base types ranges in PostgreSQL can handle NULL values, but it does not stop there. There are also special states specifically applicable to data type ranges: empty and infinity.

Let’s start with infinite bounds, the bound that shows the real power of the ranges. You can define range that extend infinitely in either direction (or both at the same time).

-- range that never expires (upper bound is infinite)
SELECT '[2025-11-01 10:00, infinity)'::tstzrange;

-- range that has always been valid (lower bound is infinite)
SELECT '[-infinity, 2025-11-01 10:00)'::tstzrange;

-- range covering all time
SELECT '[-infinity, infinity)'::tstzrange;

This gives you ability to describe the "from this points forward" use cases. As we will cover later we can easily define lifetime subscription.

```sql
-- lifetime subscription that never expires
INSERT INTO subscriptions (user_id, plan, active_period)
VALUES (42, 'lifetime', '[2025-11-01, infinity)');

-- all active subscriptions right now
SELECT * FROM subscriptions
WHERE active_period @> NOW();

Using infinity is far more elegant solution that using NULL values or “special” values like 2099-31-12 - it’s explicit and clearly communicates the data intent.

At any point you can validate whatever range has infinite bounds:

SELECT
lower_inf('[2025-11-01, infinity)'::tstzrange) AS lower_is_infinite,
upper_inf('[2025-11-01, infinity)'::tstzrange) AS upper_is_infinite;

Understanding NULL vs empty: Schrödinger’s Range

Ranges can be NULL or empty, and these are completely different things. NULL is Schrödinger’s range - you haven’t looked in the box yet, so it could be anything or nothing. Empty is when you’ve opened the box and confirmed it’s empty.

Let’s see this in practice:

-- NULL range: we don't know what the period is
INSERT INTO seat_holds_native (seat_id, user_session_id, hold_period)
VALUES (42, 'abc-123', NULL);

-- empty range: we know the period is explicitly "nothing"
INSERT INTO seat_holds_native (seat_id, user_session_id, hold_period)
VALUES (43, 'def-456', 'empty');

The main difference between them is when it comes to handling.

SELECT NULL::tstzrange && '[2025-11-01, 2025-11-08)'::tstzrange;
-- Result: NULL (not true, not false—we don't know)

SELECT 'empty'::tstzrange && '[2025-11-01, 2025-11-08)'::tstzrange;
-- Result: false (we know it doesn't overlap)

And you can check for them in your queries using built-in function isempty.

-- check for NULL (like any column)
SELECT * FROM seat_holds_native WHERE hold_period IS NULL;

-- check for empty (special function)
SELECT * FROM seat_holds_native WHERE isempty(hold_period);

In practice, you’ll mostly use NOT NULL constraints to prevent NULL ranges entirely. Empty ranges are useful but rare - usually for representing cancelled/void periods you need to keep for special purposes - like audit trail.

Practical Integer ranges for Tiered pricing

While we introduced ranges we mostly paid attention to the date/time handling the usefulness of range types goes well beyond that. One of the practical applications where integer ranges provide real values can be demostrated on tiered pricing.

CREATE TABLE quantity_discounts (
discount_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
product_id INTEGER NOT NULL,
quantity_range INT4RANGE NOT NULL,
discount_percentage NUMERIC(5,2) NOT NULL,

-- no overlapping tiers
EXCLUDE USING GIST (
product_id WITH =,
quantity_range WITH &&
)
);

INSERT INTO quantity_discounts (product_id, quantity_range, discount_percentage) VALUES
-- 1-9 units: no discount
(1, '[1,10)',     0.00),
-- 10-49 units: 5% off
(1, '[10,50)',    5.00),
-- 50-99 units: 10% off
(1, '[50,100)',   10.00),
-- 100+ units: 15% off
(1, '[100,1000)', 15.00);

-- verify what discount we offer for ordering 75 units?
SELECT discount_percentage
FROM quantity_discounts
WHERE product_id = 1
AND quantity_range @> 75;
-- Result: 10.00

Making Bad Data Impossible

If the introduction of the range types provided the case for cleaner schema you can go ahead and make hard limits structurally impossible. While this is not advocating for the transition of the full business logic into database schema, you can eliminate the edge cases that should never make it to the database.

CREATE TABLE promotional_campaigns (
campaign_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
name TEXT NOT NULL,
active_period TSTZRANGE NOT NULL,
budget_range NUMRANGE NOT NULL,
discount_percentage NUMERIC(5,2) NOT NULL,

-- campaigns must be at least 1 days long
CONSTRAINT campaigns_minimum_duration
CHECK (upper(active_period) - lower(active_period) >= INTERVAL '1 days'),

-- budget must be between $1000 and $100000
CONSTRAINT campaigns_valid_budget
CHECK (budget_range <@ numrange(1000, 100000, '[]')),

-- active period must not be empty
CONSTRAINT campaigns_valid_period
CHECK (NOT isempty(active_period))
);

While this example demonstrates hypothetical example within the schema definition, please remember they shouldn’t be used to implement business process. The goal of the constraints is to enforce data integrity, i.e. structure requirements (minimum duration, non-empty data), physical or domain boundaries. Any other logic should make it’s way either to application logic or parts that are easier to modify (think functions).

Multiranges: When one range is not enough

Up until now, we’ve been working with single continuous ranges. But what happens when you need to represent fragmented ranges? In past you needed a separate table with a foreign key relationship. With multiranges, you can store multiple non-contiguous ranges in a single column.

PostgreSQL 14 introduced multirange types for all the built-in range types:

• int4multirange, int8multirange, nummultirange
• tsmultirange, tstzmultirange, datemultirange

The real power of multiranges lies in schema density and query efficiency. We can prove this by comparing the cost of storing and querying the exact same data using two different valid range schemas.

Let’s consider storing 20 fragmented and non-contiguous periods - a pattern common for historical data.

CREATE TABLE user_periods_single_range (
period_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
user_id INTEGER NOT NULL,
active_period TSTZRANGE NOT NULL
);

CREATE INDEX user_periods_single_range_gist_idx
ON user_periods_single_range
USING gist (active_period);

-- 20 fragmented periods for user_id 42 (20 rows total)
INSERT INTO user_periods_single_range (user_id, active_period)
SELECT
42,
tstzrange(
'2025-01-01'::timestamptz + (i * 2 || ' days')::interval,
'2025-01-01'::timestamptz + (i * 2 + 1 || ' days')::interval
)
FROM generate_series(1, 20) AS s(i);

compared to 1 row for the same 20 periods aggregated using range_agg function to consolidate data.

CREATE TABLE user_periods_multirange (
user_id INTEGER PRIMARY KEY,
active_periods TSTZMULTIRANGE NOT NULL
);

CREATE INDEX user_periods_multirange_gist_idx
ON user_periods_multirange
USING gist (active_periods);

-- consolidate the 20 TSTZRANGE rows into 1 TSTZMULTIRANGE row
INSERT INTO user_periods_multirange (user_id, active_periods)
SELECT
user_id,
-- range_agg function automatically handles merging adjacent ranges
range_agg(active_period)::TSTZMULTIRANGE
FROM user_periods_single_range
WHERE user_id = 42
GROUP BY user_id;

consider now the difference between

EXPLAIN
SELECT period_id, user_id
FROM user_periods_single_range
WHERE
user_id = 42
AND active_period @> '2025-01-20 12:00:00+00'::timestamptz;

QUERY PLAN
-------------------------------------------------------------------------------------------------
Bitmap Heap Scan on user_periods_single_range  (cost=4.19..13.67 rows=1 width=12)
Recheck Cond: (active_period @> '2025-01-20 13:00:00+01'::timestamp with time zone)
Filter: (user_id = 42)
->  Bitmap Index Scan on user_periods_single_range_gist_idx  (cost=0.00..4.19 rows=6 width=0)
Index Cond: (active_period @> '2025-01-20 13:00:00+01'::timestamp with time zone)

and same version of the consolidated data

EXPLAIN ANALYZE
SELECT user_id, active_periods
FROM user_periods_multirange
WHERE
user_id = 42
AND active_periods @> '2025-01-20 12:00:00+00'::timestamptz;

QUERY PLAN
-------------------------------------------------------------------------------------------------------------
Index Scan using user_periods_multirange_pkey on user_periods_multirange  (cost=0.15..8.17 rows=1 width=36)
Index Cond: (user_id = 42)
Filter: (active_periods @> '2025-01-20 13:00:00+01'::timestamp with time zone)

Giving you significant reduction in the query cost. And while the example was simple enough for the demonstration purposes you can easily define the helper schema for better indexable data access and opportunities to reduce the storage requirements.

One important note is that subtle change with the && operators. Whereas with single range && operator checks if two continues ranges overlap, for multiranges the operator checks if ANY range in multirange overlaps.

Creating custom range types

While PostgreSQL provides built-in range types for common data types, you can create custom range types for any data type that has a meaningful ordering. Let’s demostrate this with a type for IP address ranges.

To create a custom range type, you need to provide a subtype difference function that tells PostgreSQL how to calculate the “distance” between two values:

-- function to calculate difference between two IP addresses using bigint
CREATE OR REPLACE FUNCTION inet_diff(x INET, y INET)
RETURNS FLOAT8 AS $$
SELECT (
(host(x)::inet - '0.0.0.0'::inet) -
(host(y)::inet - '0.0.0.0'::inet)
)::float8;
$$ LANGUAGE SQL IMMUTABLE STRICT;

-- custom inetrange type
CREATE TYPE inetrange AS RANGE (
subtype = inet,
subtype_diff = inet_diff
);

-- convert CIDR ranges to inetranges
CREATE OR REPLACE FUNCTION cidr_to_inetrange(cidr CIDR)
RETURNS inetrange AS $$
SELECT inetrange(
host(network($1))::inet,
host(broadcast($1))::inet,
'[]'
);
$$ LANGUAGE SQL IMMUTABLE STRICT;

Now you can use these custom types just like the built-in ones:

CREATE TABLE ip_blocklists (
blocklist_name TEXT PRIMARY KEY,
blocked_range inetrange NOT NULL
);

INSERT INTO ip_blocklists (blocklist_name, blocked_range) VALUES
('attack #434401', cidr_to_inetrange('192.168.1.0/24')),
('attack #434401 (1)', '[203.0.113.50,203.0.113.99]'),
('attack #434401 (2)', '[203.0.113.143,203.0.113.159]');

and locate which attack has been assigned to particular malicious IP address.

SELECT blocklist_name, blocked_range
FROM ip_blocklists
WHERE blocked_range @> '192.168.1.25'::INET;

blocklist_name |        blocked_range
----------------+-----------------------------
attack #434401 | [192.168.1.0,192.168.1.255]

But wait a second, wasn’t the fragmented nature of the ranges used in case for multiranges? Building real-life production and auto adaptive block list would most likely soon create extremely fragmented set of targets to block.

Can we defined it for our custom range types? Well no, because PostgreSQL is amazing! Since PostgreSQL 14 every time you define custom range type, it will automatically create corresponding multirange! Making it easy to consolidate the fragmented data corresponding to individual attack to multiranges.

SELECT typname FROM pg_type WHERE typname LIKE 'inet%range';

typname
----------------
inetmultirange
inetrange

Danger zone! When creating a custom range type the subtype_diff function is more than just simple helper. It plays important role in indexing and query performance. It really tells PostgreSQL planner how far apart the values in range are, which is crucial when building GiST indexes for ranges.

In our example above, if inet_diff returned 0 for every pair of IP addresses, PostgreSQL would think all ranges are “equally close”. This would lead to un-balanced indexes, with large hotposts in the indexes. End result would be that range operators would effectively be almost as slow as sequantial scans.

Performance deep dive: GiST vs GIN

Throughout this article, we’ve been using GiST indexes almost exclusively, particularly when enforcing exclusion constraints. But PostgreSQL also supports GIN indexes for range types, and understanding when to use each can make the difference between a query that completes in milliseconds versus one that grinds your database to a halt.

Before we deep dive, let’s recap what those two indexes do. GiST (Generalized Search Tree) is a balanced tree structure that organizes ranges by their bounding boxes, and grouping those that are “close together” in same tree nodes. While GIN (Generalized Inverted Index) would decompose ranges into their components and indexing those. Therefore GiST works for continous ranges (timestamps and numerical values), while GIN works for discrete ranges (as you can’t generate unpredictable range of values of floats for example). Given this characteristics you can almost certainly say GIN indexes are almost always going to be bigger compared to the GiST ones, as they are always trying to index a continous space.

The most important thing to know upfront? As we already used without explicitely mentioning it - you can’t use GIN with EXCLUDE constraints. GiST is mandatory there.

Therefore while GiST index is going to be preferred for cases like

CREATE TABLE seat_holds (
hold_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
seat_id INTEGER NOT NULL,
hold_period TSTZRANGE NOT NULL
);

the GIN index is actually preferred for

CREATE TABLE venue_blackouts (
venue_id INTEGER,
blocked_dates DATERANGE NOT NULL
);

The reason is simple - dates are discrete type. There’s only 365 (or 366) combinations in a given year. While timestamps have microsecond precision - millions of possible values per day.

The complexity of the index types is far beyond this article scope, so let’s just iterate over basic rules what index type to use. Most applications should just use GiST and move on. The performance difference rarely matters until you’re dealing with millions of rows and very specific query patterns. Don’t prematurely optimize - GiST is the safe, versatile default that works well for almost everything. You can always add a GIN index later if profiling shows it would help. PostgreSQL’s query planner is smart enough to pick the better index when both are available.

Conclusion

From my experience range types represent one of PostgreSQL’s most underutilized features, yet they offer immediate benefits: cleaner schemas, built-in data integrity, and query patterns that feel natural once you embrace them. What started as a solution to prevent double-booking seats evolved into a comprehensive look at how treating ranges as first-class citizens transforms your database design.

But we’ve really just scratched the surface. Timestamp ranges in particular open an entire world of possibilities we haven’t touched - temporal tables. The ability to maintain complete historical records with automatic versioning, query data “as of” any point in time, and track changes without cluttering your schema with audit columns deserves its own deep dive. That’s a topic for a future article.

For now, the next time you reach for separate start and end columns, stop and ask yourself: “Should this be a range?” More often than not, the answer is yes. Your future self - the one debugging a problems in least convenient time - will thank you.