Pricing doesn't seem competitive

Just want to say I’ve enjoyed prototyping with Neon recently. It offers almost everything I need in a database setup easily (could do with more regions, Australia please :slight_smile: ). With the recent pricing released I can now start to consider using it for production. After some evaluation, the pricing seems to be a bit steep, but please correct me if I’ve misunderstood anything. I’ll mainly be comparing to Supabase, AWS, and Fly.io as they are who I’m currently evaluating Neon against.

Neon compute is between 0.25CU and 7CU where 1CU is 1 vCPU and 4GB RAM. I assume the 0.25CU is equivalent to 1 Shared vCPU and 1GB as specified on the free tier.

Assuming a low but consistent traffic app that has at least 1 query every 5 minutes would have the Neon compute active for the entire month but with the smallest CU available (0.25CU), the pricing would be roughly as follows (excluding other costs):

1 Shared vCPU 1GB RAM (0.25CU)
Neon - $0.0255/hour (US East) → ~$19/month
RDS db.t4g.micro 2 vCPU - $0.016/hour → ~$12/month
Fly - $ 0.00792/hour-> ~$6/month
Supabase free and pro tier includes 2 Core ARM - Free or $25/month

This means that at this sort of regular traffic, in terms of Compute time, Neon is only cost efficient compared to Fly if you have utilisation of less than ~30% for the database each month.

I understand Neon Postgres has some cool features like data branching and offers a lot more than Fly Postgres (Fly is not managed), but even compared to what’s offered by Supabase and AWS RDS, it doesn’t seem that competitive. Yes Supabase and RDS can’t scale to zero, but this only benefits apps that have very infrequent database hits, which is good for hobby apps, but not for production apps which are more likely to be always up.

There is also little information on how Compute Units scale up and down. For all I know it could default unnecessarily to 1 CU in the Pro tier, resulting in much higher than the above estimated costs.

On top of this, while there is a nice Free tier, there are no free allowances in the Pro tier that are typical in other platforms for storage, compute, writes, or data (e.g. Fly provides 130GB free bandwidth, 3GB storage etc). This would help ease in to costs when one needs to transfer from the Free to Pro plan. Or one can simply start off with the Usage based plan, but with confidence they won’t be charged until they reach the free limits, and have their app scale automatically if needed.

12 Likes

Hello! Thank you for the kind words and your feedback. We greatly appreciate this type of engagement from our community.

With regards too pricing our goal is to offer “great value at a fair price”. This is why we chose a pure usage based model in which there are no additional fees for add-ons such as scale to zero, autoscaling, project sharing, data branching, read replicas, team features and more! Our philosophy is that if you use the service, and find value, you pay and if you don’t then we won’t collect a dime.

In terms of how Neon’s services compare to other vendors we believe that our feature set, ease of use and ease of maintainability provides a valuable solution to increasing developer productivity. In addition, our prices are based on supporting a sustainable and long lasting business so that we can be a reliable partner to firms of all sizes with varying needs. Of course, we take yours and all feedback quite seriously and will observe the market to identify if we need to make adjustments.

Thank you for bringing this up. If you have additional questions or feedback you can always follow up at my email atli@neon.tech.

Note: In our Pro tier Compute Units (CU) can be scaled between 0.25-7 CU and after 5 minutes of idle activity compute will scale to zero. We will soon ship a feature that allows users to configure this 5 minute interval.

For additional regions, we are evaluating user feedback as well as where we see the most growth. Support for Australia has certainly come up a few times!

4 Likes

I’m not sure we compare the same things. For example Neon architecture would be more comparable to RDS HA or even Aurora, adding support tickets even on free tiers !

I’m more afraid about egress and written data, it’s more difficult to anticipate and compare.

2 Likes

I came here looking to talk about the same thing. The pricing seems off. Unless someone is specifically required to use PostgreSQL, why not use a service such as PlanetScale which offers 1 billion row reads/mo, and 10 million row writes/mo, for free. And the next tier up is $30/mo with 10x read/writes. I love the “pay for what you use” mentality, but usually “pay for what you use” means you pay less, not more.

8 Likes

Just want to add that this kind of pricing FEELS sneaky even though I know it’s not intended to be. As the OP says, even if you have 2 users in your dinky application, you might technically be “on” half or more of the hours of the month, depending on how the application works. And what if it’s a 1kb transaction every 30 mins? You get the full spanking of the pricing model for being “on.” Also gives the company the opportunity to implement changes that cause users to be “on” more than intended and therefore, more profit from users. I’m sure they wouldn’t but… hourly models feel…. seedy somehow.

Exciting tech, but not a fan of these “hourly” pricing models. Always assume full 24 hours of use just to be safe… then the pricing doesn’t look so hot.

In general, we observe that users’ bills are largely driven by how many Compute-hours they use in a month. A Compute-hour is: # Active-hours (time spent using the database) * # Compute-units (CU). 1 CU is equivalent to 1 CPU & 4GB RAM which represents the amount of compute resources dedicated to your database.

If you have a very active application, generally eCommerce or B2C, you will have, on average, a database that is running 24X7 or for 730 Active-hours a month. On the other hand, if you have an internal application for the database then its usage will reflect the working month or approximately 173 hours a month of active usage.

After understanding how long your database will be running for, on average, you should understand how much performance your workload requires. For most applications, with moderate usage, 1 CU is more than sufficient. We currently host a database for Vercel, RoomGPT, which has over 80K visitors a day and does more than fine on 1 CU.

Here is an example of your Compute-hour bill in different scenarios (from our billing docs):

I thought I might chime in again since new pricing has been announced and give some feedback on it.

I really appreciate the move towards simpler pricing. Removing the charges for written data and data transfer is a great step for predictability. Simplifying pricing across regions is also great. To cover this cost I see that Neon has increased the price of extra usage for compute time and storage which is completely fair, however if I’m not mistaken, the cost for storage seems to have increased ~10x, and the cost for compute by ~30%.

I see the extra storage cost in the scale tier is listed as $15 per 10GiB, does that mean the moment you need an extra 1mb, you are charged the full $15?

I see some people are taking issue with the jump in cost between tiers, and not being able to scale between them, especially if their usage is on the boundary between tiers. For the launch tier, this is made worse by not offering additional storage. Someone who needs 11GiB instead of 10, but is satisfied by the launch tier compute time, all of a sudden needs to pay an extra $50. If you’re not trying to take advantage of these cases, why not allow people to scale between tiers with their needs by allowing additional storage in the launch tier?

It seems that having 2 paid tiers is probably unnecessary and just complicates things. I think you could keep the current pro tier at $3/month, and like with the new simplified pricing only charge for compute, and storage, with adjusted rates compensating for the lack of charging for data, and flat pricing across regions. This would then be more in line with the serverless mantra of only pay for what you use.

Hi @joshiain !

Thank you so much for your feedback, and sorry for the delayed response. You make some very valid points that we appreciate and have considered.

We’ve now updated our Launch plan, and users can add additional storage at $3.5 per 2 GB. This covers those users who just need a bit more storage but are not ready to upgrade to the Scale plan quite yet.

Also, you observe (rightfully so) how Neon’s per-GB storage pricing is higher than other managed Postgres providers. This pricing is not at all set in stone, we keep iterating on it—you could expect some updates and improvements soon. But it’s perhaps worth explaining why this price point may seem higher than what it really is in practice:

  • Neon’s storage is very different than any other managed Postgres, since Neon implements a custom-built storage engine that keeps snapshots of all database history (up to a user-configurable retention period). This is what makes our storage instantly “brancheable”, among many other things.
  • Why is this relevant for pricing: in Neon, instead of paying for database copies/forks for dev, testing, or staging instances, teams create branches, and they don’t pay extra for storage when doing so. They create one branch per engineer (vs paying for dev instances), one branch per PR, one branch per every test, one branch per staging… With one storage bill.
  • This is why many of our customers still see a reduction in their storage bill when moving to Neon over their entire deployment, even despite the higher price point per GB. This price seems expensive side by side, but things change when you look at the overall bill. In a way, this price per-GB stretches well over 1 GB.

Hope this was useful. Please keep sharing your feedback and experiences, it truly help us improve Neon.