[jamesmcintyre]

This is cool! A few questions:

- Given how neon architecture decouples compute with storage using the safekeepers & pageservers will this still just work with neon? (Wondering because you mention the index is in-memory so unless your stateless compute nodes can somehow hot-swap the indexes I wasn't sure how that'd work?)

- Do you plan to offer vector search as a plug-and-play offering? If so does neon as a product offering plan to introduce more "out-of-the-box" functionalities like vector search? (Similar to xata's offerings like search & vector search.)

- unrelated question- I believe neon has very small cold startups for free/scale-to-zero configurations but are there also inherent small latencies for infrequently accessed data? In other words is it safe to say if there were a large table with records that are "old"/"archival" but also always a sort of ~last 30-days of records that are "fresh"/"accessed with more frequency" would there more likely be slight latency introduced when accessing the older records?

Neon looks awesome and thanks for neons open source contributions!

[nikita]

Great set of questions:

- This does work with Neon today, please go ahead and try. Today the index is in-memory and we are working on the on-disk implementation. Neon architecture does make it trickier - no local disk, so we are actively experimenting as we speak. Anything we ship will of course work on Neon.

- We will start with vector ANN and see the reception and user feedback. Now that we have 100K databases we are super attuned to what our users tell us.

- There is a cache/storage hierarchy: local cache on compute, cache on pageserver, and S3. We are working on cold start (stay tuned for more announcements this week). The goal is to make this unnoticeable for the app.