WHERE timestamp > now() - 30s in 2026

If you searched for WHERE timestamp > now() - 30s, your intent is usually a real-time freshness filter for event streams, polling, or replay protection. The logic is correct, but SQL syntax changes by engine. In 2026, the safe pattern is to use each database's interval function and compare against a native UTC timestamp column.

Most failures happen when milliseconds are compared to seconds, or when a text field is queried as if it were a timestamp. Keep values normalized, use integer epoch conversions when needed, and validate output against a trusted converter before shipping.

2026 SQL examples

PostgreSQL

SELECT *
FROM events
WHERE created_at >= NOW() - INTERVAL '30 seconds';

MySQL

SELECT *
FROM events
WHERE created_at >= NOW() - INTERVAL 30 SECOND;

SQL Server

SELECT *
FROM events
WHERE created_at >= DATEADD(second, -30, SYSUTCDATETIME());

Related EpochConverter pages

For the base query explainer, read timestamp now minus 30s. For engine-specific details, open PostgreSQL syntax guide and MySQL syntax guide.

Need to debug raw values during query tests? Open the main epoch converter tool.

Related developer tool

If this query runs on a schedule, validate interval jobs with Cron Expression Builder.

Frequently Asked Questions

Is `WHERE timestamp > now() - 30s` valid SQL?

Not directly in most engines. Use PostgreSQL `NOW() - INTERVAL '30 seconds'`, MySQL `NOW() - INTERVAL 30 SECOND`, or SQL Server `DATEADD(second, -30, SYSUTCDATETIME())`.

Should the filter use UTC time?

Yes. Store timestamps in UTC and compare against UTC-aware functions to avoid timezone drift between services and databases.

Why does this query miss rows in production?

The common causes are seconds-vs-milliseconds mismatch, string timestamps instead of native timestamp columns, and out-of-sync server clocks.

Do I use `>` or `>=` for a 30-second window?

Use `>=` for inclusive boundaries and `>` for strict boundaries. Pick one consistently across jobs and dashboards.