Sign in Subscribe

One Year at a Database Startup Called Neon

David Gomes

• 9 min read

Precisely one year ago, I joined Neon, a company building a Postgres managed service with some modifications to core Postgres that allow for the decoupling of storage and compute. I had seen firsthand at SingleStore the benefits of such a database architecture, and I also knew how hard it is to build it properly.

My hypothesis was that Neon had a unique and powerful engine to build upon. In fact, I recall that around the time I joined, the company had just replaced its tagline from "Serverless Postgres" to "Ship Faster with Postgres" — indicating a desire to become a more complete service for application development (and not just a database product). This made me really excited about the mission!

But to be honest, while I admired the product, what really drives me at the end of the day is working with great people. And what got me to join Neon in the end were the people behind the tech, as I was extremely impressed by everyone I met during the interview process. So, despite every career decision like this coming with some risk, I knew I'd be in good hands.

The First Few Months…

My team’s scope was ill-defined to start, as I was tasked with making Neon a more complete development platform (i.e., more than just a database service). As such, our team got the name "BaaS Team" (Backend-as-a-Service Team).

The first feature we picked up was Neon RLS, which had already been started before I joined. This is an innovative take on how to get Postgres’ Row-Level Security to work seamlessly with authentication providers such as Auth0, Clerk, Keycloak, Okta, AWS Cognito, WorkOS, etc. It was somewhat inspired by what Supabase was doing with their Supabase Auth feature, but designed in such a way that it can work with any auth provider (eventually Supabase shipped something very similar as well, and they called it "Third-Party Auth", which is arguably a better name).

Neon RLS is not groundbreaking, and it didn't make Neon stand out that much from other Postgres providers. However, it is unique, and we’ve attracted customers with interesting use cases.

Neon RLS adoption from October 2024 to June 2025

I have blogged a bunch about Neon RLS in the past:

All in all, Neon RLS was the perfect project to get me acquainted with the team, the codebase and how to get things done.

Moving on to Neon Auth

While working on Neon RLS, we realized Neon as a platform had a pretty significant issue. While we had Neon RLS to interop Postgres RLS with auth providers (Auth0, WorkOS, Keycloak, Okta, Azure AD, Clerk, Stytch, etc.), developers building an app would still have to go and sign in for an authentication provider and get everything "wired up".

With that in mind, we decided, during a full company in-person offsite, to ship our own authentication product. But alas!, building an authentication product is really hard and we didn't have the resources nor the appetite to become an authentication service company ourselves. So, we decided to partner with our friends over at Stack Auth in order to build Neon Auth. If you haven't heard of Stack Auth, it is a fully open-source replacement to products like Auth0 or Clerk. And with Neon Auth, you just get it out of the box batteries-included for every Neon project you create! What's more, you get tables in your database with all of your auth data. This means that you can easily do SQL JOINs against your user data, which is very useful.

This partnership is constantly evolving, but it's been amazing to see it grow over the last few months. Specifically, I'd like to highlight that a product called Databutton (a "prompt to app" AI agent software builder like Replit) is now using Neon Auth + Neon Postgres for every app they generate:

We made Supabase obsolete and suddenly 74% of our support tickets are gone. | David Gomes
Sign in or join now to see posts like this one and more.
LinkedInPetter Trobe

This is amazing! It really showcases the power of open-source, as well as of batteries-included software. There's still a ton of work to do here, but the path ahead is exciting.

The Neon Data API

The Neon Data API is a ready-to-use REST API for your database. This was definitely inspired by the work that other players in the space are doing (mainly Supabase and Firebase, but also Nhost, Hasura and others). The idea behind it is that for simple apps, you don't have to code your own backend, because we can automatically generate one for you from your database schema and your Row-Level Security policies.

This was only launched 3 days ago (as of the writing of this post), and while it already has some usage, it's still in Public Preview. We will blog about this soon in order to properly announce the feature. Now, while I can’t disclose why, I have to say I’m particularly excited about this blog post (there will be some surprises there! 😁).

Also, the team has put together a really cool demo app which features both Neon Auth + Neon Data API on GitHub, so definitely check it out if you're curious.

Wait... What about MCP? And AI?

So, on November 25th, 2024, Anthropic announced a new protocol called Model Context Protocol. Since then, it has taken the AI ecosystem by storm.

We like to ship fast at Neon, and we mean it. So, by December 3rd 2024, we had already launched our MCP Server (and I recall that companies like Cloudflare and E2B were just as fast).

I worked on this with Pedro, and it was a lot of fun to work on such brand new technology with almost no references to follow. Our MCP server has now grown to a lot of users through Cursor, VSCode, Windsurf, other IDEs and web products like Same.new!

More recently, the MCP protocol adopted authentication/authorization as part of its specification, which allowed us to likely become the first company in the world to have a remote MCP server (running at mcp.neon.tech). This time, Shridhar put in the bulk of the work to make it happen in record time.

As we've been in the bleeding edge of the MCP protocol development, we've been able to work directly with some of the core MCP folks to develop the protocol futher. We've all learnt a ton about AI engineering throughout all of these efforts. And again, I've blogged and given a couple of talks on this topic, sharing what we've learned:

Building "app.build" in 2025

Over the last few months, I joined a second team and we started working on a brand new project called app.build. This one was perhaps a bit unexpected by a lot of people, but we decided to create an AI app builder based on the following hypothesis:

  • Codegen is going to change the world; we need to develop our codegen "muscle" at the company.
  • AI Agents are going to change the world; we need to develop our AI engineering "muscle" at the company.
  • We have a bunch of partners leveraging Neon for their AI App builders (Replit, Same.new, v0, Databutton, Create.xyz, and more), so it's really important that we "dogfood" Neon for this as well, and learn firsthand about any issues that Neon might have for this use case. Yes, you can rely on your customers to tell you all about it, but doing it yourself helps a lot too. And knowledge is power!
  • Open-source is the way forward for innovation. Whatever we build here should be open-source, and we should share our learnings with the world.
    • In our launch blog post, we included some high-level details about the architecture.
  • Many of the existing app builders are "lazy" about generating a fully working backend and database, and almost none of them generate end-to-end tests or run linters and type checks.

After a few months of hard work, the product is now live! Here's a quick demo from the initial release:

We just open-sourced 𝐚𝐩𝐩.𝐛𝐮𝐢𝐥𝐝, a reference implementation for building codegen products on top of Neon: https://www.app.build/ | Neon
We just open-sourced 𝐚𝐩𝐩.𝐛𝐮𝐢𝐥𝐝, a reference implementation for building codegen products on top of Neon: https://www.app.build/ app.build is based on everything we’ve learned helping agent platforms scale, including Replit, v0, same.new, and Create.xyz. It's our blueprint for building AI agents using the Neon platform. Generated apps use: - Neon Postgres for the database - Neon Auth for authentication - Fastify + Drizzle ORM for the backend - React + Vite for the frontend - Playwright for end-to-end testing - GitHub for repo + Actions (CI/CD) - Koyeb for deployment You can use it as-is, fork it, or extend it to build your own agent infrastructure. It’s not a product per se but it’s a reference implementation, built to be hacked on. Explore the code: https://lnkd.in/g6Tx7sk8
LinkedInView Profile

The entire thing is open-source on GitHub, so feel free to learn more there. This is a very new project as of the writing of this blog post, but I'll just say that we have a ton of new features coming out, as well as a lot of content about the agent and its inner workings. Stay tuned!

Joining Databricks (The Acquisition)

Neon recently joined Databricks! Yes, that's right, Neon, the company, no longer exists. And I'm now a Databricks employee. However, the Neon brand (https://neon.com) is alive and kicking. It will continue to serve as our vehicle to acquire smaller customers, while Databricks Lakebase reinvents the world of OLTP for the enterprise.

I have only officially been a Databricks employee for a couple of weeks, so I'm mostly in very-active learning mode at the moment. The first week was especially fun with all of us being together in person in San Francisco:

Since then, we've been exploring how we can be most impactful at the new "mothership", and there's a number of projects that I'm eager to get to work on soon.

For now, however, I decided to put this blog together since the last 12 months have been a blast. The many teams at Neon have absolutely crushed on their execution, and I'm especially proud of the teams that I'm a part of for their hard work and continued commitment to excellence.

Before I wrap it up, I'd just like to add that I've been incredibly fortunate to get to do some "devrel" type work over my tenure at Neon. I had done a bit of this before, but definitely took it up a notch after I joined Neon:

This type of work was fulfilling in a different way from my "main responsibilities". It allowed me to travel and to meet many great individuals from different companies in the space. One of the things that definitely made Neon so successful is the fact that we took partnerships and connections really seriously. This is visible in the sheer number of externally connected Slack channels I'm a part of, and how much effort we put into all of those relationships.

I also want to give Nikita a special shoutout since he's founded two amazing databases companies—SingleStore and now Neon—that have both marked my career and impacted my life tremendously. There's only an extremely small number of people in the startup world that have been able to achieve this kind of success. Unfortunately, it's very hard for normal people like me to be able to recognize the difficulty of pulling these things off, and also the level of responsibility and stress that come with it. If you're reading, thank you for the opportunities Nikita!

And finally, everyone at Neon has welcomed me and taught me a lot, and for that I'm very grateful. I can't wait to see what lies ahead... onwards and forwards!

Oh yeah, I also moved from Lisbon to Madrid with my wife one year ago, so what a year it has been!

Feel free to reach out on Twitter/X!

Sign up for more like this.

Enter your email
Subscribe