mfreed

- Almost certainly. In fact, there is already a submitted PR contribution for larger dimensions.

- C is much better integrated into Postgres, doesn't require pgrx. Given also experience developing pg_textsearch, and the acceleration from AI-assisted development and testing, have moved back to more C with extensions.

- Two reasons. First, decision to move back to C. Second, if there ultimately isn't much code overlap, better to keep them separate for easier adoption (smaller footprint and security/correctness envelop)

Fair question. When we built our first vector extension, pgvectorscale, we actually reached out to pgvector's author to see if they'd be interested in supporting additional index types (at the time, DiskANN-based), so we could contribute our work directly to pgvector. At the time, their preference seemed to be to focus on the existing index types rather than expand the project in that direction. We respected that decision and went ahead with a separate extension.

But one of the great things about open source and PostgreSQL's extension architecture is that these projects can coexist! pg_vectorsearch can work directly with pgvector's existing data types, so developers can use either index.

We're also the authors behind pgvectorscale. From our blog post:

This isn’t the first vector index we’ve built and open-sourced for PostgreSQL. In 2024, Tiger Data released pgvectorscale, which used a graph-based indexing algorithm inspired by Microsoft’s DiskANN research. We deliberately chose a disk-optimized design so that indexes could scale beyond available RAM. Our initial benchmarks were promising, but as adoption grew and we tested against a wider variety of datasets, particularly low-dimensional ones, we encountered a troubling problem: portions of the graph could become unreachable, causing recall to degrade. We searched the literature for a principled solution but couldn’t find one, and the heuristics we tried worked on some datasets but not others.

That’s a frustrating failure mode for a search index. When queries are slow, you can measure the problem and tune accordingly. But when recall degrades, you might not even notice until users start questioning the quality of their search results. And telling them to experiment with yet another set of tuning parameters isn’t the experience we want to provide.

Meanwhile, partitioned-list approaches reminiscent of IVFFlat were getting a second life, as advances in compression and optimization addressed many of their old limitations. More importantly, they offered stronger guarantees than we could achieve by patching a graph-based index. We came to believe they were a better foundation, and decided to start over.

With the introduction of pg_vectorsearch, we are shifting the majority of our vector-search development efforts to this new architecture. The existing pgvectorscale extension, which is stable and handling production workloads currently, will enter maintenance mode.

github.com/timescale/tigerfs

Hey, author here. Just noticed this.

Yes, TigerFS works well with local PG - in fact, all of my testing framework uses this setup.

Big upside of this is latency; main downside is that such a deployment is primarily "single user mode."

One very interesting approach of this is ability to transparently share state / collaborate across machines, with these transactionally serialized at the common database.

I primarily work with Postgres, including both at scale and in very ephemeral environments. So just haven't looked at all what doing with this SQLite would mean.

None of this. It's in the blog post in a lot of detail =)

The 5ms write latency is because the backend distributed block storage layer is doing synchronous replication to multiple servers for high availability and durability before ack'ing a write. (And this path has not yet been super-performance-optimized for latency, to be honest.)

Currently support multi-AZ clusters and multi-region disaster recovery (continuous PITR between regions).

We're continuing to evaluate demand for multi-region clusters, love to hear from you.

Tiger Cloud certainly continues to run on AWS. We have built it to rely on fairly low-level AWS primitives like EC2, EBS, and S3 (as opposed to some of the higher-level service offerings).

Our existing Postgres fleet, which uses EBS for storage, still serves thousands of customers today; nothing has changed there.

What’s new is Fluid Storage, our disaggregated storage layer that currently powers the new free tier (while in beta). In this architecture, the compute nodes running Postgres still access block storage over the network. But instead of that being AWS EBS, it’s our own distributed storage system.

From a hardware standpoint, the servers that make up the Fluid Storage layer are standard EC2 instances with fast local disks.

A few datapoints that might help frame this:

- EBS typically operates in the millisecond range. AWS' own documentation suggests "several milliseconds"; our own experience with EBS is 1-2 ms. Reads/writes to local disk alone are certainly faster, but it's more meaningful to compare this against other forms of network-attached storage.

- If durability matters, async replication isn't really the right baseline for local disk setups. Most production deployments of Postgres/databases rely on synchronous replication -- or "semi-sync," which still waits for at least one or a subset of acknowledgments before committing -- which in the cloud lands you in the single-digit millisecond range for writes again.