September 2023 Summaries

The Hierarchical Navigable Small World (HNSW) index has been introduced in Postgres, allowing for vector search to scale with the database. However, due to overlap and redundancy between HNSW and pgvector, pg_embedding will be sunsetting and its efforts will be redirected towards pgvector. This move aims to streamline the experience for Postgres users and contribute to a single project, pgvector, in the vector search space. The team is committed to improving vector search in Postgres and actively participating in discussions on pgvector, working on techniques to address challenges with larger datasets.

pg_embedding is being phased out in favor of pgvector for vector search in Postgres, as the latter now includes the Hierarchical Navigable Small World (HNSW) index, making it more efficient and beneficial for the Postgres community. The decision to retire pg_embedding is driven by the desire to avoid confusion and redundancy, focusing instead on a single, more robust solution. Users of pg_embedding can continue to use it on Neon but are encouraged to migrate to pgvector, with a migration guide available. The transition aims to streamline vector search development, with ongoing efforts to enhance pgvector by experimenting with new techniques like the Vamana index and improving parallel index building and real-time updates. The commitment remains to deliver effective solutions for Postgres users, with a focus on making vector search more efficient.

Vector search is an essential component of Generative AI applications, enabling AI models to understand which texts are semantically similar. pgvector is a Postgres extension that allows vector search, and its latest release includes a new graph-based index for approximate nearest neighbor (ANN) search known as Hierarchical Navigable Small Worlds (HNSW). HNSW makes vector search queries significantly faster and more responsive. It creates a multi-layered graph to quickly traverse layers to find approximate nearest neighbors, allowing developers to balance the trade-offs between index quality, query speed, and resource usage. While HNSW offers impressive speed, it provides approximate results, is resource-intensive, and can be complex to tune for optimal performance.

Vector embeddings are a crucial component of Generative AI applications, serving as a representation of complex data in a format that AI models can process to discern semantic similarities. Pgvector is a PostgreSQL extension that facilitates vector similarity searches, crucial for applications requiring nearest neighbor searches, such as those using large language models (LLMs). The latest version, pgvector 0.5.0, introduces the Hierarchical Navigable Small Worlds (HNSW) index, an approximate nearest neighbor (ANN) algorithm that enhances search speed significantly, making AI applications more responsive. The document details how vectors represent data points in multi-dimensional space and outlines the mechanics of similarity searches using both Euclidean and cosine distance metrics. It further explains how pgvector supports these searches by allowing the creation of efficient HNSW indexes, which balance speed and accuracy through parameters like `m` and `ef_construction`. These indexes are resource-intensive but offer scalability and high recall, making them well-suited for large datasets. By incorporating pgvector and HNSW, developers can build scalable and responsive AI applications, although they must consider the trade-offs related to resource usage and tuning complexity.

Neon's serverless driver allows for the use of Postgres at the Edge with Vercel Edge Functions, providing a convenient solution for applications that require database operations in edge environments. The driver separates compute and storage, making it suitable for use with Next.js API Routes. It offers flexibility in querying using SQL-over-HTTP or WebSockets, depending on the application's needs. With Neon, developers can utilize Vercel Edge Functions to read and write data, enabling efficient and scalable database operations at the edge of the network.

Neon's serverless driver is designed for use with Vercel Edge Functions, allowing users to work with a Postgres database in edge environments by separating compute and storage. Unlike traditional Postgres, which relies on TCP/IP connections, Neon's driver utilizes HTTP or WebSockets to connect to a Postgres database via a Neon proxy, making it compatible with edge environments like those based on V8 isolates. The article demonstrates how to integrate Neon's serverless driver with Next.js, highlighting the simplicity of setting up a Postgres database and executing SQL queries from edge functions. The example application, "Ping Thing," showcases how users' geolocation data can be collected and visualized using Vercel's geolocation services, illustrating the potential for capturing user data and enhancing analytics. This approach provides an efficient and flexible solution for developers looking to leverage serverless Postgres databases in modern web applications, with the capability to store and analyze geolocation data to better understand user interactions.

Postgres 16 introduces several performance improvements and developer experience enhancements, including expanded support for SQL/JSON syntax with the introduction of new functions such as JSON_ARRAY(), JSON_ARRAYAGG(), and IS JSON predicate. These features allow developers to construct and manipulate JSON data more efficiently and effectively, enabling them to build more robust and scalable applications. With Neon's support for Postgres 16, users can take advantage of these new capabilities and improve their development workflow, making it easier to work with JSON data in PostgreSQL.

Postgres 16, now supported by Neon, introduces significant enhancements for handling JSON data, including the expanded SQL/JSON syntax with functions like JSON_ARRAY() and JSON_ARRAYAGG(), as well as the IS JSON predicate. JSON_ARRAY() constructs JSON arrays from a series of values or query results, while JSON_ARRAYAGG() operates as an aggregate function to compile input values into a single JSON array. The IS JSON predicate enables checking if expressions can be parsed as JSON, identifying their types such as scalar, object, or array. These new features, some contributed by the Neon Postgres team, aim to improve performance and the developer experience. Neon encourages users to explore these capabilities and engage with their community for further feedback and discussion.

Scaling Prisma applications with Neon read-only replicas is a game-changer for improving performance and scalability. By leveraging read-only replicas, developers can offload read traffic from their primary database, achieve higher throughput, and provide access to specific users or applications while preventing any impact on the performance of read-write application workloads. Neon's read-only replica feature offers cost effectiveness, data consistency, and instant availability, making it an attractive solution for scaling Prisma applications. With its separate storage and compute architecture, Neon's read replicas are independent read-only compute instances that perform read operations on the same data as your read-write computes, ensuring a high degree of data consistency. Additionally, developers can create read-only replicas with minimal configuration using Neon's Pro plan or the Neon CLI, and connect to them using Prisma Client extensions such as @prisma/extension-read-replicas.

Neon read-only replicas provide a scalable solution for Prisma applications by allowing read traffic to be offloaded from the primary database, enhancing performance and scalability without additional storage costs. Unlike traditional Postgres, Neon utilizes an architecture that separates storage and compute, with read-only replicas functioning as independent compute instances that access a single data source, ensuring data consistency and instant availability. Neon’s read-only replicas leverage features like Autoscaling and Auto-suspend for cost-effective resource management. To implement this in Prisma, developers can use the newly released @prisma/extension-read-replicas, which allows read operations to be directed to read-only replicas while write operations remain with the primary database. This setup is achieved by extending the existing Prisma Client with the extension and configuring it to connect to Neon read-only replicas, offering an efficient method to scale applications.