Zero to Hero: Neon - Serverless Postgres for Stellar Startups

I came for the serverless, and stayed for the vibes

From Zero to Hero is a series dedicated to empowering software developers, small teams, and founders with game-changing tools and services. Each edition spotlights a low-barrier, high-leverage solution that can dramatically accelerate your project's journey from concept to reality. Drawing from years of experience in building products from the ground up, this series offers practical insights, real-world applications, and actionable challenges to help you maximize your productivity and impact. Whether you're a solo developer, a startup founder, or part of a growing team, From Zero to Hero equips you with the knowledge to make informed decisions about the tools that can propel your projects forward. Join me as we explore the solutions that punch above their weight, proving that with the right tools, even the smallest teams can achieve heroic results.

Introduction

I'm thrilled to kick off this series with a service I've grown to love over the last year: Neon. I've recommended it to several people, and today I'll detail why it's so awesome. While my enthusiasm might sound like a paid endorsement, I assure you I'm simply a satisfied paying customer. 😅

What is it?

Neon is a modern, cloud-based database service that offers a serverless version of PostgreSQL, one of the most popular open-source relational database systems. Neon itself is also open-source. Neon is like having your favorite high-end oven (PostgreSQL) in a cloud kitchen. You get all the power and familiarity of Postgres, but without the hassle of maintaining the hardware or infrastructure – just show up and start cooking with your data. Let's explore how this analogy plays out in Neon's unique features and benefits.

What are the benefits?

For the business

Autoscaling to the rescue

Neon is a serverless cloud offering, so the immediate benefit to businesses is that it allows usage-based billing that is "right-sized" to your workload. In practice, rather than paying for a static database server, a business pays only for the compute and storage a Neon database utilizes. Neon's core innovation is separating compute and storage¹, and billing for them separately. Compute is what is used at query-time to retrieve data, while storage simply represents all the data in the database and any historical snapshots (more on this later). Separate compute and storage, and separate their separate billing enables businesses to buy "just enough" database rather than under-provisioning to save money, or over-provisioning to mitigate traffic spikes.

Autoscaling saves you more than money

Neon's serverless core offers more than just potential cost savings; it also helps teams maintain operational excellence. As mentioned earlier, Neon can scale up and down based on traffic. This means your product and site can handle sudden traffic spikes, like after being featured in a popular publication. Scalability like this is made all that much sweeter because it's dead simple to configure. The following is the way I've configured my Neon instance (though there are other ways as well).

Because of configuration like this you can also be sure about what your minimum and maximum spend will be for the month; this is a subtle but important distinction, since many teams are frustrated that a lot cloud services do not afford pricing transparency. Autoscaling without cost transparency is like driving a car without side mirrors or seatbelts - risky and potentially disastrous.

Neon helps you to better serve your customers

Neon's scaling benefits extend well beyond a single database instance or application; provisioning new databases can be done programmatically, and its provisioning is fast (a few seconds vs a few minutes in traditional managed database services). This opens up possibilities for businesses, like a multi-tenant architecture where every customer has their own database. Having worked in B2B Saas for over 10 years, a capability like this is music to my ears because oftentimes multi-tenancy is a hard requirement for customers. Furthermore, the autoscaling makes such an architecture cost-effective. For example, your biggest customer can get a beefy database instance that rarely or never suspends, while your lower tier customers can use cheaper autoscaling instances that scale to 0 when not in use.

An insurance policy

Neon supports a killer feature that I consider a huge insurance policy against incidents and anomalies: time travel. Specifically, Neon allows developers to issue queries against a specific point-in-time or database transaction. The importance of this cannot be understated. Imagine if you have a new developer starting with your team and they mistakenly issue a disastrous query that deletes a bunch of customer data. Not only can you create query before the incident to ascertain the damage, you can also restore the database entirely. It's worth noting that PITR (point-in-time-recovery) is a fairly standard feature amongst managed database services. What makes Neon's offering unique are speed and the developer experience. In Neon performing a PITR is painless and fast. Neon also offers a time travel query editor, which is a unique offering I have not seen elsewhere. The retention window for history is also configurable, up to 30 days, depending on tier. To be clear: this is an additional safeguard and is not a replacement for backups. It's a pretty sweet safeguard though, because it's impactful and easy to use. Finally, I'd be remised if I didn't mention that time travel can be used as a poor man's data warehouse since an engineer or analyst can issue historical queries. Similarly, this is not a replacement for a proper data warehouse, but it can be fairly effective in a pinch, especially for a small team.

Closing

In essence, Neon's business benefits extend far beyond cost savings. It's about empowering your team to focus on innovation rather than infrastructure management, providing peace of mind with robust safeguards, and offering the flexibility to adapt to your business's unique needs. Whether you're a startup or an established enterprise, Neon's serverless PostgreSQL can be a game-changer for your database strategy.

For developers

We've covered how Neon can help drive business outcomes, but what about the developer experience? After all, while the business may benefit from a good strategic decision, it's ultimately developers that will be responsible for maintaining and leveraging a service like Neon.

The Neon team ❤️ Postgres

Here's a hot take: it's crucial that the people building in a technology ecosystem genuinely care about both the ecosystem and the technology itself. The reason is simple: if they're not nerding out about the tech, how can you trust they're putting out the best work? How can you trust you won't eventually be hampered by their decisions? I don't know much about the Neon team itself, but in this respect their actions speak volumes. First, Neon is completely Postgres-compatible, so they're not fighting to replace the venerable database. As mentioned earlier, Neon itself is open source.

The Neon team's ethos is important, but delivering value to customers and developers matters too. And here they excel as well. On launch day, Neon supported the latest and greatest: Postgres 17. That's an impressive turnaround, and I can tell you from experience this is not the norm for managed database services. This is an important indicator in my view because it means that as an engineering team, you can leverage the latest and greatest as soon as possible. Postgres is rock-solid in terms of stability, and so the ability to leverage any new developer features is huge. In the past, I've found new Postgres features are able to improve significant portions of an application almost overnight. New features also typically open up new use-cases. One notable improvement  in Postgres 17 specifically, is the updated MERGE command. This updated command can dramatically improve upsert queries, and move them away from the application, which in turn improves overall stability.

Neon also embraces the broader Postgres ecosystem, so developers are fully empowered to innovate. It supports major open source extensions, including Postgis for geospatial applications, timescaledb for time-series data, amongst others. On the AI front, Neon has stellar support for pgvector, which can serve as a very good vector database. Similar to Postgres major versions, I've observed the Neon team supports new versions of extensions very quickly; this is especially important with regards to pgvector, which is evolving rapidly as teams build out AI applications.

A delightful developer experience

While Neon's robust Postgres support is great, it's the exceptional developer experience that truly sets it apart.

I've discussed history in the context of business continuity but it's also an invaluable developer tool. Neon makes it so frictionless to use historical data that it's very practical to use it to troubleshoot bugs. Imagine this scenario: a bizarre bug crops up at 1:31 AM, and replicating your system's state to reproduce it seems impossible. With Neon, it's a breeze: simply branch your production data as of 1:31 AM and use that new branch in your local development environment. Oh, I forgot to mention, Neon has branching for your data! This is what makes using history so seamless. Basically, like git, different "versions" of a database instance can exist as different branches. Branches can be forked and cloned, and these operations are fast. This extends beyond debugging too. If you're developing a new feature and want realistic data, what's better than just forking production? Each branch gets its own unique endpoint that can be referenced wherever you like. After a branch is forked, the branch histories diverge, just like git; changes in a base branch do not affect the base branch. The ability to treat data like code is such a superpower, I can't overstate its importance.

Pictured: me expressing my excitement for Neon's branching feature.

This feature's potential goes even further. Neon has a Github actions integration that allows you to create branches on a PR-basis. If you have a preview environment capability for your application (which most PaaS support), this effectively means you have a complete replica of your production environment. Branching won't be feasible for all teams out-of-the-box. In particular, some teams may need to scrub sensitive customer data before allowing access to developers (eg financial services, health tech). However, teams can address this with 3rd party vendors that specialize in data scrubbing, or automate it themselves.

The cherry on top of Neon's developer tooling is its comprehensive and well-documented API. If your team has specialized needs, you have the power to implement them. All the aforementioned features, like branching, creating databases, and editing scaling parameters are scriptable via the API.

The final notable developer tooling feature that I want to cover is endpoints. I've mentioned how branches each get their own endpoint, but this is not limited to branches. Each Postgres database (not to be confused with the Neon database instance) gets its own endpoint. Each endpoint can then be separately configured with its own scaling parameters. This combination is powerful because it allows for more flexible architecture choices. For example, if separate database instances is not your preferred architecture for multi-tenancy, you can simply create separate databases within a single instance, each with it's own endpoint (and by extension its own scaling). Similarly, Neon also has a native read replication functionality, which leverages endpoints. So for example, a complex analytics query won't take down your production endpoint, and in fact your read replica can be scaled independently from your production configuration.

One small thing I recommend developers look out for: make sure your database connections are correctly configured in whatever framework or library you're using. I spent some time debugging my Neon instance because it would scale to zero (as I configured), but my backend then tried connecting to a closed connection; my backend automatically caches database connections.

This is trivial to address, but it's not something I've had to do coming from non-serverless databases. In Django, I configured CONN_HEALTH_CHECKS so that Django's ORM first checks the status of the connection before attempting to use it. Similarly, in Sqlalchemy, I configured pool_pre_ping, which works much the same way as Django's setting.

Closing

As you can see, Neon has a complete toolbelt to make developers' lives easier and more productive. From lightning-fast provisioning to intuitive branching and historical querying, Neon has reimagined what a cloud database service can offer. It's not just about storing data; it's about empowering developers to work smarter, faster, and with greater confidence. In a world where developer productivity is paramount, Neon stands out as a tool that truly understands and enhances the developer experience.

Low Barrier, High Leverage Assessment

Now, let's summarize Neon's offering and rate it as a low-barrier, high-leverage solution. I also discuss some areas where I think it could be improved.

Barrier Lowerers

• Neon is open source and Postgres compatible, so getting started is a breeze.

• Autoscaling reduces the amount of decision-making teams need to make around workloads.

• Neon's branching feature allows for easy testing and development without affecting production data, reducing the barrier to experimentation.

• The comprehensive API enables teams to integrate Neon seamlessly into their existing workflows and automation pipelines.

Leverage Lifters

• Neon's developers tools are top-notch.

• Neon's support for the latest Postgres versions and extensions ensures your team can leverage cutting-edge database features as they become available.

• The ability to create separate databases with individual endpoints allows for flexible architectural choices that can evolve with your business needs.

• As your team and business grow, Neon's scalability and branching features support increasingly complex development workflows and multi-tenancy requirements without requiring a fundamental change in your database strategy.

Areas for Improvement

• I didn't cover this earlier, but Neon has connection pooling support. However, it requires using a separate endpoint. Connection pooling is generally considered a best practice, and I would love if this were the default out of the box, and didn't require separate configuration.

• I love Neon's history feature because it serves as both an insurance policy and as a developer power-up. I wish history could be configured completely independently of the tiering. Currently, the first paid tier tops out at 7 days of retention, and the next tier up is good for 30 days. I would like to pay for this independently of the other features, but I understand why this tiering makes sense from a customer segmentation perspective.

• Neon currently supports instances in AWS, and Azure support just launched in beta. I think it's inevitable but I look forward to having Neon on all major clouds, so it's a no-brainer for any team. I know of at least one team that cannot use it because they are using GCP. Technically, anyone can use the existing instances, but using a database in a different cloud is a suboptimal.

Scoring

I'm scoring Neon a 9/10 for having a low barrier to entry, and a 10/10 for the leverage it affords teams, for a combined score of 9.5/10.

I subtracted a point for lowering the barrier to entry because of the areas where Neon can improve. Neon is a startup, so I expect these minor shortcomings to be addressed in time (with the exception being paying for the history feature independently, which is more of a pricing strategy complaint).

Conclusion

I've been itching to dive deep into Neon for a while now, and for good reason. It's a rare gem in the database world that combines the robustness of PostgreSQL with cloud-native innovations like autoscaling, branching, and time travel. From its business benefits of cost-efficiency and operational excellence to its developer-friendly features that boost productivity, Neon is reshaping how I think about and interact with databases. I've recommended it to numerous teams, and the feedback has been consistently positive. Whether you're a startup looking for a scalable solution or an enterprise seeking to modernize your database infrastructure, Neon deserves a serious look. It's not just a database service; it's a catalyst for better, faster, and more innovative software development.

1. It's worth mentioning that serverless database products predate Neon, in Amazon Aurora and other offerings. However, Neon is the first offering I'm aware of that is open-source and not tied to a specific cloud.