N
Neon3mo ago
flat-fuchsia

NeonDB pricing for zero sync engine (for enabling logical replication)

I'm looking to migrate my postgres database from supabase to neon, but I do not understand the pricing implications for doing so, considering I need to enable logical replication since I am using zero sync engine. If I understand correctly, zero sync engine requires will cause each database to which it is connected to never go idle? 1. How much compute hours would this setup consume considering zero never lets the database go to sleep? Would this mean 31 x 24 = 744 hours/month per database? 2. Are compute hours charged per database or per branch? 3. If we move our development setup to remote neon DBs, will that also incurr additional costs because of the logical replication? Ideally I would go for a "1 Database per-Tenant" approach, but not sure if I'd then have to pay for the logical replication for each tenant/database, which could get prohibitive. Basically I want to understand how much would it cost, I am currently hosting on supabase for $19/month, but would be willing to evaluate paying a bit more for neon, just want to see if it gets prohibitively expensive. Can anyone share some light? Estimates are fine, it's more to have an idea, as I haven't really understood the compute hours pricing.
5 Replies
optimistic-gold
optimistic-gold3mo ago
If your database never sleeps due to ongoing logical replication, you're right. You'll need to calculate active hours for your database x compute size to figure out how many compute hours you'll consume over a month. For a 1 vCPU compute, this calculation looks right: 31 x 24 = 744 hours/month For a .25 vCPU compute, it would be 1/4 of those hours. Each Neon plan comes with an allowance of compute hours included in the monthly fee. Here's a pricing estimation guide you can look at: https://neon.com/docs/introduction/pricing-estimation-guide Question 2/3: Each branch has it's own compute. You would need to calculate compute hour usage for each. However, you might be able to use branching to avoid logical replication on your development branches. You can create/update copies of your production DB instantly & use small computes & scale to zero to keep compute costs low. Please consider reaching out to our sales team to walk you through pricing for your use case. https://neon.com/contact-sales
Neon
Pricing estimation guide - Neon Docs
You can use this guide to estimate your monthly bill with Neon based on your selected plan and estimated usage. 1. Select your plan and note the monthly fee 2. Estimate your usage 3. Calculate extra u...
Neon
Contact Sales — Neon
Interested in learning more about our plans and pricing? Contact our sales team.
flat-fuchsia
flat-fuchsiaOP3mo ago
Thanks for your thorough response @Daniel 🙏 , it cleared things up quite a bit. Unfortunately for our use case, this makes it inviable, since a sync engine will indeed keep the database awake at all times. Pretty unfortunate considering sync engines like https://zero.rocicorp.dev and/or https://electric-sql.com are an ever-more popular use case, but I guess they are inviable in combination with serverless databases except pricing is adjusted somehow to accomodate these use cases. Would be interested to know if this is something Neon is considering or could evaluate?
optimistic-gold
optimistic-gold3mo ago
I'll check with the team to see what they think. We're definitely interested in supporting those sync engines.
flat-fuchsia
flat-fuchsiaOP3mo ago
That would be great! I will make sure to update the zero community of any news 🙌
conscious-sapphire
conscious-sapphire3mo ago
Solving this or at least providing some insight would be super helpful for smaller side projects with limited budget! I love the idea of a managed db and having logical replication to use electric sql or something like inngest, but the always on nature for logical replication makes this tough (mainly from a cost perspective). Even if there was a way to subscribe to a webhook where i could be notified of a change and query the db would be great. Not a postgres expert by any means, so not sure how doable this would be.

Did you find this page helpful?