nikita

13 ms·

121.
by nikita 3y ago
This means that the index is persisted in Postgres pages which are durable against restarting Postgres. Our previous version what fully in-memory and wasn't "durable".
122.
Pgvector Meets HNSW Index(neon.tech)
3 points by nikita 3y ago|0 comments
123.
by nikita 3y ago
CEO of Neon here. After we built an in memory HNSW index for Postgres that allowed us to establish a baseline in performance and prove that it's the right approach to support vector search we now built it "the right way" and
124.
On-disk HNSW index for Postgres with pg_embedding(neon.tech)
63 points by nikita 3y ago|28 comments
125.
We Raised another $46M – What’s Next?(neon.tech)
2 points by nikita 3y ago|0 comments
126.
by nikita 3y ago
Neon CEO here. AMA
127.
by nikita 3y ago
Neon CEO here. Happy to answer questions!
128.
by nikita 3y ago
(CEO of Neon). There is a TL;DR: of this blog post: https://twitter.com/nikitabase/status/1680636526823370752
129.
by nikita 3y ago
Replicas are eventually consistent. Consider a replica a few ms behind.
130.
by nikita 3y ago
Thank you for submitting (CEO of Neon here). Happy to answer questions on our design decisions.
131.
by nikita 3y ago
Can our team reach out? please email nikita@neon.tech and we will help you out.
132.
by nikita 3y ago
Happy to work with you on that!
133.
by nikita 3y ago
https://github.com/pgvector/pgvector/pull/86 an example of why it's better to have our own project to move fast.
134.
by nikita 3y ago
I think IVFFlat and HNSW are very different implementations. So we would be forcing a choice for a pgvector user of what index to use. Our on disk path will require us to run a number of experiments with the storage format. We will move fas
135.
by nikita 3y ago
Can you say more about the use case?
136.
by nikita 3y ago
Would love to work with you on that! Please dm to https://twitter.com/neondatabase
137.
by nikita 3y ago
https://github.com/neondatabase/pg_embedding/blob/main/LICEN...
138.
by nikita 3y ago
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 ex
139.
by nikita 3y ago
CEO of Neon here. This was a relatively quick project for us and the index is currently in-memory. However it is fast! We would love your feedback and excited to invest further.
140.
20x faster than pgvector: HNSW index in Postgres with pg_embedding(neon.tech)
101 points by nikita 3y ago|52 comments
141.
by nikita 3y ago
CEO of Neon here. We have done a lot of latency work. Feel free to ask questions.
142.
HTTP vs. WebSockets: Which one is the fastest for Postgres queries at the edge?(neon.tech)
105 points by nikita 3y ago|48 comments
143.
by nikita 3y ago
The incident was resolve by the time i wrote the comment
144.
by nikita 3y ago
Neon experienced an outage: https://neonstatus.com/cliq6zf8d173102wonc0x3upawc Some projects may still be impacted and the team is actively investigating
145.
by nikita 3y ago
Neon is as consistent as Postgres. B/c it's Postgres. All we did was swapping storage.
146.
by nikita 3y ago
How do you run it?
147.
by nikita 3y ago
No, the compute shuts down on inactivity in 5 minutes regardless of active connections.
148.
by nikita 3y ago
Neon works at the storage level: https://neon.tech/docs/introduction/architecture-overview So all extensions including Timescale work. Postgres does the heavy lifting
149.
by nikita 3y ago
Neon CEO here. Happy to answer questions about the serverless driver and beyond.
150.
by nikita 3y ago
Neon CEO here. Autoscaling with live VM migrations is quite cool. Here is a blog post on it: https://neon.tech/blog/scaling-serverless-postgres And yes, the code is open feel free to use it!

More ›