Queries are 2x faster, but we're making some event properties temporary

TL;DR

• We're rebuilding how PostHog stores events making queries about a third faster on average, and up to 2x faster for common queries.
• $set, $set_once and other short-lived debugging properties on events are now kept for 60 days instead of forever.
• $feature_flag_called events and $feature/* properties move to dedicated storage built for them. Most queries on flag calls keep working, but a few need a change.
• We're removing some deprecated properties, mostly flag payloads and internal SDK state.
• We'll drop null values and empty objects from properties, and store a few built-in properties as text. See what this changes.
• These changes will also impact batch exports of events: flags arrive as one map, and some properties are left out or added as empty values. See what changes for batch exports.
• Other person and event properties are unaffected. They stay on your persons and on every event, queryable as before.
• All of this takes effect on November 30.

We're making queries faster

Every event you capture is stored in one very large table, and until now, we stored much of each event twice: once as raw JSON and again as columns for fast querying. That made the table slow to change and expensive to scan.

We're moving to a format that stores each property once, with its real type (numbers stay numbers, booleans stay booleans). This takes far less storage, and a query reads only the properties it asks for.

Here's what we measured by replaying real production queries against the new format:

Replay, error tracking, AI observability, experiments and PostHog AI all got faster, but for transparency, queries over many custom properties improve least (a few may even be slightly slower).

Why we're making some properties temporary

We looked at how event properties get queried. A small set, mostly SDK diagnostics and person-update instructions like $set, are useful for debugging right after an event arrives. After that these are almost never queried, but we stored it forever on every event.

$set and $set_once are the biggest part of this. They're instructions to our person-merging engine ("update this person's properties"), which we apply the moment an event arrives. The result is stored on the person and on every event as person properties. Keeping the raw instruction forever also meant storing the same data twice, both the properties and the instructions on how to change the properties.

From November 30 2026, we will keep these properties for 60 days before dropping them. This means you can still inspect them and use them to debug, but they won't be included on persons or events forever. This means less data stored twice in PostHog and faster queries for everyone.

Moving feature flag data to its own table

Another set of events and properties we store duplicates of is feature flags. Again, these are mostly used to debug flags and make sure they are working, but bog down the rest of events table doing so. To prevent this, we're moving $feature_flag_called events to their own table and then dropping them after 90 days. We're also changing $feature/<flag> from one property for each to one map per flag.

Here's more details on what this means:

Do you need to change anything for flag calls?

Probably not. Insights, funnels, cohorts, actions, experiments, and SQL queries on $feature_flag_called keep working. From November 30, they show at most the last 90 days of flag calls. Destinations and workflows that explicitly set $feature_flag_called as a trigger will continue to work. Paths that read every event, or that build steps from a SQL expression, no longer include $feature_flag_called events.

Two exceptions:

• SQL with SELECT *, SAMPLE, or FINAL: a query that reads $feature_flag_called with any of these returns an error. List the columns you need instead of *, and remove SAMPLE and FINAL.
• Batch exports and Destinations: from November 30, exports of the events table or all events will not include $feature_flag_called events. To keep exporting them with batch exports, see What changes for batch exports. For destinations, tell us if you need them.

We'll email you before your organization moves. For details, see Where does PostHog store flag calls?

What properties expire after 60 days

These properties stay queryable for 60 days after we receive the event, then we delete them. The event and all its other properties are kept as normal.

Good to know:

• Person properties are not affected. We apply $set and $set_once to the person as soon as the event arrives. The resulting person properties stay on every event and stay queryable as before. Only the raw instruction on the event expires.
• The 60 days count from when we received the event, not from the event's timestamp.
• Historical events: on November 30, events we received more than 60 days earlier (before roughly October 1) lose $set, $set_once and the other properties in this table. Their person properties are kept.
• Not affected: $sent_at, $sdk_debug_current_session_duration and $debug_images stay permanent, because people use them in longer-term queries and for error symbolication.

What properties we're removing

These properties are deprecated, and we'll stop storing them on events.

Queries using $active_feature_flags keep working. HogQL translates them to the new feature flags map, so existing insights and queries won’t break. For new queries, use the map directly.

Raw LLM payloads already live somewhere else. $ai_input, $ai_output and the rest moved to a dedicated AI observability table with 30-day retention, which keeps very heavy data off the events table and AI observability affordable. Any copies still on the events table are legacy data older than 30 days, so removing them changes nothing in the product.

How some property values change

We'll drop null values and empty objects from properties, and store a few built-in properties as text. You'll mostly see this where PostHog shows a whole event, like batch exports, the API, and event details.

What changes for batch exports

From November 30, batch exports that use the events model change in two ways:

• They no longer include $feature_flag_called events, because these events move to their own table. You can export that table separately (see below).
• They send properties and person_properties in the new storage format. This format stores feature flags more efficiently, so events with many flags are much smaller.

This applies to every destination. The persons and sessions models don't change.

Here's everything that changes in exported events:

Here's an example of the properties of one event in a batch export before November 30:

{
  "$browser": "Chrome",
  "$browser_version": 131,
  "$referrer": null,
  "$feature/new-checkout": true,
  "$feature/pricing-test": "variant-b",
  "$feature/legacy-nav": false,
  "$active_feature_flags": ["new-checkout", "pricing-test"],
  "$set": {"email": "user@example.com"}
}

And the same event in a batch export after November 30. The list of empty built-in properties is shortened:

{
  "$browser": "Chrome",
  "$browser_language": "",
  "$browser_version": "131",
  "$device_type": "",
  "$exception_list": [],
  "$feature_flags": {"legacy-nav": "false", "new-checkout": "true", "pricing-test": "variant-b"},
  "$os": "",
  "$session_id": ""
}

When

The changes take effect on November 30. Questions? Get in touch with support.