PostgreSQL current_timestamp vs now

As a database consultant, I’ve encountered many developers confused about timestamp functions in PostgreSQL. One question that repeatedly comes up is: “What is the difference between current_timestamp and now() in PostgreSQL”

PostgreSQL current_timestamp vs now

Let’s start with the short answer: current_timestamp and now(). They are functionally equivalent in PostgreSQL. They both return the current date and time with timezone information (timestamp with time zone).

However, there are technical distinctions and usage scenarios where choosing one over the other makes more sense. Let’s dive deeper into the details.

Before examining the specific differences, it is essential to understand the broader context of timestamp functions in PostgreSQL.

What is a Timestamp in PostgreSQL?

In PostgreSQL, a timestamp is a data type that stores both date and time values. PostgreSQL offers two timestamp types:

1. timestamp – Stores date and time without timezone information
2. timestamp with time zone (or timestamptz) – Stores date and time with timezone information

Both current_timestamp and now() return values of type timestamp with time zone.

current_timestamp vs. now(): Technical Comparison

Let’s examine how these two functions compare from a technical perspective.

Syntax

• current_timestamp: This is an SQL standard function. It follows the ANSI SQL specification and is part of standard SQL. You can use it with or without parentheses: current_timestamp or .
• now(): This is a PostgreSQL-specific function. It’s not part of the SQL standard but is widely used in PostgreSQL codebases. You must include the parentheses: now().

As PostgreSQL documentation indicates, now() returns the same timestamp within the same transaction. Understanding this behavior is crucial when working with these functions.

Function Behavior Within Transactions

Both functions return the timestamp from the start of the current transaction, not the current statement. This behavior has significant implications that I will explain with examples.

According to the search results, “now is a constant evaluation of the current transaction’s start time”. This means that if you call either function multiple times within the same transaction, you’ll get the same value each time.

Let me demonstrate with an example:

BEGIN;
SELECT now();
-- Returns: 2025-04-30 10:30:45.123456+00
-- Wait for a few seconds...
SELECT now();
-- Still returns: 2025-04-30 10:30:45.123456+00
COMMIT;

This behavior is identical for current_timestamp.

You can check out the same expected output as shown in the screenshot below.

When Transaction Time Consistency Matters

This transaction-level consistency can be either a feature or a bug, depending on your use case. Here’s why:

Benefits of Transaction-Level Consistency

When processing multiple operations that require referencing the same “current time” within a transaction, this consistency ensures that timestamps remain synchronized. For example:

• Creating multiple related records that need the same timestamp
• Performing calculations based on “now” that should remain consistent within a transaction
• Ensuring log entries related to a single transaction share the same timestamp

Limitations of Transaction-Level Consistency

However, there are scenarios where this behavior might not be what you want:

• Long-running transactions where you need to track when individual operations occur
• Time-sensitive applications where exact wall-clock time is critical
• Performance benchmarking within transactions

When to Use current_timestamp

We can use current_timestamp In the following scenarios

1. When writing cross-database compatible code: Since it’s part of the SQL standard, your code will be more portable if you ever need to migrate to another database system.
2. In SQL standard compliance environments: Some organizations have coding standards requiring adherence to SQL standards.
3. For better code readability: Some developers find current_timestamp more descriptive and self-explanatory than now().

When to Use now()

Similarly, we can use now() In these cases

1. In PostgreSQL-specific codebases: When portability isn’t a concern and you’re committed to PostgreSQL.
2. For brevity in queries: It’s shorter to type and read in complex queries.
3. When following established team conventions: Many PostgreSQL teams traditionally use now().

Performance Considerations

In terms of performance, there’s virtually no difference between current_timestamp and now(). Both are highly optimized, and the choice between them won’t impact your application’s performance.

However, be aware that clock_timestamp() It involves additional system calls to get the current time, which could theoretically be slightly slower in extremely high-volume scenarios. In practice, this difference is negligible for most applications.

Timezone Handling

Both current_timestamp and now() return timestamps with timezone information based on the server’s timezone setting. This is an important consideration when working with applications that serve users across different timezones.

To see your current PostgreSQL timezone setting:

SHOW timezone;

Check out the screenshot below, we got the expected output.

You can change the session timezone with:

SET timezone = 'America/New_York';

After changing the timezone, both current_timestamp and now() will return values in the new timezone.

Comparison Table: PostgreSQL Timestamp Functions

Here’s a quick reference table summarizing the key differences between PostgreSQL’s timestamp functions:

Function	Returns	SQL Standard	Format	Consistent Within Transaction
current_timestamp	Transaction start time	Yes	With timezone	Yes
now()	Transaction start time	No	With timezone	Yes

Conclusion

To summarize what we’ve learned:

1. current_timestamp and now() are functionally identical in PostgreSQL – they both return the timestamp from the start of the current transaction with timezone information.
2. The main difference is that current_timestamp is SQL standard compliant, while now() is PostgreSQL-specific.
3. If you need the actual current time for each statement rather than the transaction start time, use clock_timestamp().
4. The choice between current_timestamp and now() should be based on factors like code portability, readability, and team conventions rather than functional differences.

In my opinion, I generally recommend using current_timestamp for new projects to maximize code portability and standards compliance. However, if you’re working with existing PostgreSQL-specific code that already uses now(), there’s no compelling reason to change it.

You may also like the following articles.

• How to create user in PostgreSQL
• PostgreSQL Update Limit
• PostgreSQL RANK Function
• How To Concat In PostgreSQL
• PostgreSQL ORDER BY COUNT