How Hotdata accelerates Neon and Supabase

Agents rarely connect to a single database. Transactional databases like Postgres generally store core application data, but agents often need to query multiple systems and require fast response times.

Given today’s stack, what are good options for building an application that spans multiple databases?

In this piece we compare:

• Neon: serverless PostgreSQL optimized for cloud workloads
• Supabase: a full backend platform built around PostgreSQL
• Hotdata: a low-latency, PostgreSQL-compatible multi-modal query engine

We’ll look at performance and explore where each tool fits in a project.

A Review of the Platforms

Neon: Serverless Postgres

Neon provides serverless PostgreSQL that scales to zero when idle. Its architecture separates compute from storage and supports fast branching for preview environments. It’s great as a standalone Postgres database for applications.

Key characteristics:

• You pay for compute hours used
• Compute scales to zero when idle
• Instant branching (Git-like database copies)
• Well-suited for variable workloads and many small databases

Supabase: Postgres Platform

At first glance Supabase looks similar to Neon, but it goes further than just Postgres. Supabase provides auth, real-time updates, storage, edge functions, and APIs. It’s an excellent all-in-one backend for developers who want fewer moving parts when building applications.

Key traits:

• Predictable base pricing plus usage-based costs
• Includes auth, storage, real-time updates, and an edge runtime

Hotdata: PostgreSQL-Compatible Multi-Modal Query Engine

Hotdata is a read-only cache that sits in front of your databases, applications, or APIs. It can make multiple databases feel like one, allowing joins across multiple sources.

Key characteristics:

• Optimized for fast query execution
• Data is synced in the background
• Supports structured data, vectors, and full-text search in a single query

Performance Snapshot

Neon and Supabase are common choices for agent databases because developers like Postgres for its flexibility and ecosystem. As agent workloads grow, however, both can hit performance walls. Hotdata addresses these gaps without replacing the primary database.

To illustrate the difference, we ran the ClickBench hits dataset (~100M rows, ~14GB Parquet) against each system using analytical queries involving filters, group-bys, and aggregations — the kind agents run when analyzing user data or building context.

Hotdata was consistently orders of magnitude faster than both Neon and Supabase on these workloads.

We Use Neon and Supabase to Build Hotdata

Behind the scenes, we rely on Supabase and Neon for specific use cases. We use Neon, in particular, to manage customer metadata and both serve as backing stores with well-defined transactional qualities. But when we need to aggregate and search that data, we treat them as sources that Hotdata queries directly. This lets us cache and accelerate our heaviest queries.

When Should You Use Hotdata?

• Your AI/LLM applications need fast data access: agent queries, tool calling, function execution, and context retrieval under ~50ms
• Your workloads combine multiple access patterns in a single loop: structured queries, vector search, and full-text, without stitching systems together
• You want to decouple compute from your primary database: offloading read-heavy traffic without impacting production
• You care about both latency and cost at scale: millisecond queries without paying warehouse-level costs per query