Postgres Compute Time

[mquandalle]

I recently migrated my database from Supabase to Vercel's Pro plan due to approaching the 500MB storage limit on the free Supabase plan. However, I’m disappointed with the unexpected costs associated with Vercel's "compute time" for Postgres.

In my use case, the compute time is effectively 24 hours a day. This translates to a cost of (24 hours/day * 30 days - 100 included hours) * $0.10/hour = $62/month.

This is a small database with very simple INSERT and SELECT queries that are not CPU intensive. I expected compute time to measure actual CPU usage for running queries, similar to other systems. Instead, it measures the time the database is active. Since I write to the database several times per minute, my compute time is always 24 hours/day, even for inserting just a few simple records each minute.

Including only 100 hours/month of availability on the Pro plan is misleading. For a live website, it's reasonable to query the database 24/7. It's also misleading in the documentation:

I am surprised by this pricing model. From my understanding, Supabase and Neon (which Vercel uses) measure actual CPU time, not "alive time" as Vercel does. This makes Vercel's offering significantly more expensive than alternatives.

[mquandalle]

Found other users surprised by this pricing model on X https://x.com/hesselbom/status/1762379810301464961

[adriancooney]

Hi @mquandalle. Thanks for reaching out and using Vercel Postgres.

Neon (which Vercel uses) measure actual CPU time, not "alive time" as Vercel does

Vercel uses the same compute time metric as Neon. Neon's compute time measures "alive time" as you put it - the wall-clock time for how long the compute endpoint is active and able to receive queries - multiplied by the CPU factor (e.g. 0.25 to 7). An endpoint will remain active after a request until the compute timeout has expired, it will then become idle (i.e. inactive) and sleep. The default compute timeout is 5 minutes and the minimum value is 60 seconds. You could try adjust your compute timeout down to 60 seconds which might improve your situation. If your database has at least 1 req/min, it will be active continuously however.

The explanation on the link behind the "Compute Time" title in that table might make things a little clearer:

Vercel calculates compute time based on the active time of your database, multiplied by the number of CPUs available per month. The active time includes periods when the database is receiving requests and for a duration (default 300 seconds) after the last request is received. Following this period of inactivity, the database scales down to zero, effectively pausing compute time billing.

I think you're right though - there is an opportunity to improve the documentation here and be explicit about the exact makeup of the compute time metric. I'll open an issue to get that fixed, thanks!

[mquandalle]

Thank you for answering, one thing that could also be documented is the expected latency to wake up a database that is not alive.

[adriancooney]

Neon has a great blog post on cold boot times from last year. They're always working to improve it so I'd be hesitant to add it to our documentation in case it becomes stale/outdated. Thanks for the suggestion!

[github-actions[bot]]

This discussion was automatically locked because the community moved to a new site. Please join us at vercel.community