ObsessionDB

The best ClickHouse® database performance per dollar |

[Alvaro @alvaro__data]

ObsessionDB now runs in your own AWS or GCP account.

Your data stays in your bucket and nothing on our side connects in. We run upgrades, scaling and on-call.

Cut the link to our control plane and your queries keep running.

[ObsessionDB @ObsessionDB]

Agents are hungry for data, and we are here to feed that appetite.

Meet ObsessionDB, the fastest and most scalable data warehouse for AI.

[Marc Höffl @marchoeffl]

Today we are launching @ObsessionDB, the realtime data warehouse for agents.

Your agents are hungry for data. Feeding them is getting expensive.

Your data warehouse wasn't built (or priced) for that.

We learned this the hard way. We scaled our last company to petabytes on ClickHouse and watched the infra bill go vertical.

So we built @ObsessionDB . The ClickHouse engine, rebuilt with compute and storage separated, so your infra scales with your agents instead of your bill.

100x faster and 20x cheaper than Snowflake and Databricks. Already live, processing trillions of rows a day.

Agents are just getting started...

[Rafa Aviles @avilesrafa]

Unpopular opinion: your data warehouse/platform should not make money from your waste. Today, most of them do.

Consumption pricing means your vendor earns more when your queries or schema are suck. Some of them charge crazy multiples on the underlying infra. That is not a partnership; it feels like they are extracting from you.

Data warehouses and data platforms should be more aligned with customers:

1. Infra at cost. You see the real cloud bill, line by line.
2. One platform fee. No overages. No markup.
3. Run it in your cloud, on your hardware, or go managed. No difference in the price.

If we save you money, we should win too. If your bill goes up because you burned more compute, we don't extract extra margins. The old model doesn't make any sense to me.

Is this naive?

[Rafa Aviles @avilesrafa]

We just added Jev support to ObsessionDB/ClickHouse.

The interesting part isn’t just “LLM in SQL”, it’s that Jev is fast enough to make semantic queries feel like part of the database workflow.

You can analyze AI agent sessions on the go!

aiFilter(session, 'was the user frustrated, map('model','jev-1.13.0'))

or score frustration, success, intent, exposed credentials, etc.

At write time: turn meaning into columns.

At read time: ask new questions you never instrumented.

~50 rows/request, ~300ms in our current setup.

Feels like a new primitive for AI product telemetry.

[marcmacmac @marcmacmac]

Just waiting for the PR getting merged to finally see ObsessionDB on https://t.co/vaaDROVbc6. Spoiler: It's fast

[ObsessionDB @ObsessionDB]

Locality-aware routing: sending each query to the servers that already hold its data took the same query from 1.0 s to 0.5 s on the same six servers.

Result on 56 TB: p99 703 ms, max 977 ms.

Full write-up: https://t.co/niCOLrKG6j

[ObsessionDB @ObsessionDB]

56 TB of data (203 billion rows) on ObsessionDB, with live ingestion, and we managed to run 100% of the queries in under one second.

Slowest: 977 ms.

Three things made that possible 🧵

[ObsessionDB @ObsessionDB]

4/ Third, a cache shared across servers.

With storage and compute decoupled, each server caches only what it has read/ingest. More servers means more cold caches, and each miss is a 10 to 50 ms trip to S3.

Our cache mesh lets any server read any other server's NVMe in ~0.1 ms.

[Alvaro @alvaro__data]

Three replicas of a ClickHouse® table mean three full copies of the same data.

You are paying your storage bill three times and calling it durability.

The replication tax nobody names:

[ObsessionDB @ObsessionDB]

In beta for every customer. Reach out if you want to test it.

Full entry: https://t.co/OjUVwNEIdJ

Previously in the changelog:
https://t.co/16ITjnrX8Z

[ObsessionDB @ObsessionDB]

Jul 3, 2026: a backfill is usually one enormous query you fire and hope finishes. Every ObsessionDB service now has a Jobs section for long-running batch SQL: backfills, big dataset loads, heavy maintenance. It runs task by task, and you can step in at any point.

[ObsessionDB @ObsessionDB]

Getting data from another team, vendor or customer usually means an export, a replica, or a sync job that drifts. Datashares are now in beta on ObsessionDB: one customer exposes databases or tables, another queries them directly. No copy anywhere.

[ObsessionDB @ObsessionDB]

Why no copy? Most databases are shared-nothing: each node owns its slice of data, so sharing means exporting it. ObsessionDB is shared-storage: data lives exactly once as immutable objects and compute is stateless, so another customer's compute can read the very same objects.

[ObsessionDB @ObsessionDB]

You stay in control. Pause and in-flight tasks finish cleanly; resume when ready, or cancel outright. A failed task can be retried on its own, and every attempt keeps its exact error.

Full entry: https://t.co/tMKzyudlsh

Previously in the changelog:
https://t.co/D9biakBtdl

[ObsessionDB @ObsessionDB]

Jun 23, 2026: most monitoring tells you something's broken after you go looking. We wanted the cluster to tell us first.
Alerts is live in ObsessionDB: write a SQL query, set a threshold, and we watch it for you.

[ObsessionDB @ObsessionDB]

Jul 3, 2026: a backfill is usually one enormous query you fire and hope finishes. Every ObsessionDB service now has a Jobs section for long-running batch SQL: backfills, big dataset loads, heavy maintenance. It runs task by task, and you can step in at any point.

[ObsessionDB @ObsessionDB]

Open a job and watch it run: percent complete, tasks done vs running vs waiting, data read and written, current throughput. Down to the SQL each task ran and how many rows it moved.