Neon raises $46 Million to advance serverless PostgreSQL database for the AI era

Neon, a serverless PostgreSQL database company, announced it has successfully raised $46 million in a series B round of funding.

This brings the company’s total funding raised to $104 million. Neon launched its service in 2022. The new funding round was led by Menlo Ventures, and included the participation of Founders Fund, General Catalyst, GGV Capital, Khosla Ventures, Snowflake Ventures and Databricks Ventures. Neon’s service takes the open source PostgreSQL (also referred to sometimes as ‘Postgres’)relational database and provides it as a serverless cloud service. 

With serverless, the intent is that developers building applications do not need to maintain servers, rather the database only runs when it is needed. The Neon serverless PostgreSQL offering takes an approach that has been well received in the market to date, with the startup claiming to have more than 100,000 databases deployed. Partnerships with developer cloud platforms including Vercel and Replit are also helping to drive growth.

“We’re starting to have clouds on top of infrastructure clouds and every application needs a database,” Nikita Shamgunov, CEO of Neon, told VentureBeat. “Our aspiration is to become the database for the developer clouds.”

The complexity of autoscaling, cold starts for a serverless database

As Neon has built out its service over the last year, the company has had to overcome numerous challenges.

While a key promise of the cloud has always been elastic scalability, providing autoscaling for a serverless database is not a trivial matter. Shamgunov explained that the ability to automatically provide the right amount of resources for compute and storage as demand scales up or down required engineering effort from his team to get right.

Another challenge that the Neon team worked through is the issue of ‘cold starts’ for the serverless database.  With a traditional database deployment the service is always running, but that’s not the case with serverless.  Shamgunov noted that behind the scenes on a serverless database deployment, there are virtual services that need to be started up when needed to deliver the service for a particular application. Rather than keeping those servers running continuously, Neon only starts them when needed, which leads to the cold start issue as the database needs to boot up and get running. The cold start can lead to latency in query response as it takes time for the database to be operational.

The Neon team has worked through the cold start and auto scaling issues. Shamgunov said that at one point it could take three seconds for a cold start, which isn’t an ideal situation for a production deployment. The Neon team has solved that issue in recent months and now has its cold start time down to sub-200 milliseconds and is continuing to improve, according to Shamgunov.

Neon boosting AI with vector capabilities

A growing use case for databases is alongside AI as a way to store vector embeddings. While there are purpose-built vector databases, like Pinecone, an increasingly common deployment approach is for an organization to enable an existing relational database to also work with vectors.

The PostgreSQL database already supports vectors by way of the pgvector extension.  Neon is going beyond what pgvector provides, using an additional set of algorithms with its own vector extension called pg_embedding to help further improve accuracy.

“Our own vector extension that’s called pg_embedding provides vector search and it uses one of the more modern algorithms, so it’s a lot faster than the one [pgvector]that’s already there in the ecosystem,” Shamgunov said.

Shamgunov said that he doesn’t see pg_embedding technology as being a competitive challenge to pgvector, as both technologies are open source and he’s hopeful that the pgvector project will adopt some of the same approaches that Neon’s project has taken. The primary competition is standalone vector databases like Pinecone.

“Our strength is that we’re PostgreSQL, so if you store the majority of your data in PostgreSQL and you need vector search, you don’t need a separate database,” he said.