Neon Blog

Fly.io's pricing seems fair. It's not amazingly cheap, but there aren't a lot of PaaS offerings out there and most are very expensive and have complicated pricing compared to Fly.io - even Digital Ocean's AppPlatform is more expensive.

I am curious about the freemium model for PaaS systems. I've always wondered what percent of compute ends up being free and if the paid prices have to be higher to subsidize the free tier. Would it be better for the paying customers if the service was 30% cheaper and there was no free tier? Of course, I might be incredibly far off on how much the free tier customers cost.

I think for people that think Fly.io is expensive, it just feels like what Fly.io does should be table stakes rather than a premium service in 2022 - and yet it's so hard to find! Heroku is 15 years old and Fly.io feels like the first platform I've used since that just gets it.

I would say that a collaboration between you and Neon (https://neon.tech/) would be pretty cool. While your site does link to Neon as a recommendation, Neon's datacenters often aren't that proximal to Fly.io's - Ohio isn't that close to Chicago, Virginia, or New Jersey. Maybe that'll get better in the future.

I'd always love it if Fly.io were cheaper, but more than that I'm glad that Fly.io seems to really get what customers need.

> Will EdgeDB Cloud be fully replicated similar to https://neon.tech?

Eventually yes. Our client libraries APIs are designed in such a way that it's easy for us to automatically route read queries to the nearest replicas and do other magic.

> I want to use EdgeDB Cloud but I want the latency to be that of Grafbase for example.

We'll be working on lowering the latency as much as we can. But you also have to keep in mind another aspect - which is the composability of EdgeQL, which allows you to pipeline multiple operations in one query. That query will get you all of your data in one round trip, something that doesn't typically happen with ORM libraries and SQL in general.

> 3.0 looks very exciting, well done.

Thank you!

Cool! At Neon[0], I work full time on our custom postgres proxy[1]. It's a very nice protocol to work with, although our usecase is quite a bit more complex compared to the ideas presented in the post.

Neon databases scale to zero, so the proxy needs to spin up databases on the fly. The proxy doesn't do that but it knows if the databases is running and asks our control plane to schedule it if it isn't. It's a fun service to maintain.

The biggest pain is error handling. Postgres is really bad for error messages and codes. The only available code we can use is usually protocol violation...

[0]: https://neon.tech/ [1]: https://github.com/neondatabase/neon/tree/main/proxy

A few weeks back, we released pg_embedding[1], a new extension for Postgres and LangChain which introduced Hierarchical Navigable Small Worlds (HNSW) indexes for vector similarity search. This new indexing method resulted in 20x faster queries at a 99% accuracy compared to traditional IVFFlat indexing[2].

Today, we released a new version which includes the following improvements:

1. The HNSW index is now constructed on disk instead of in memory

2. The extension now supports Cosine, Manhattan, and Euclidean distances

[1]: https://github.com/neondatabase/pg_embedding

[2]: https://neon.tech/blog/pg-embedding-extension-for-vector-search

When a blob is saved, first I write it to Postgres (https://neon.tech), so that ensures there's a persisting backup. However, it's typically a waste of money to store infrequently accessed blobs in disk with Postgres over months and years. After 4-6 weeks data is offloaded to object storage - so that you benefit from low long term storage costs.

The lifecycle of a blob works out roughly something like as follows, based on last read date:

< 30 mins ago

- In-Memory: Cloudflare CDN

< 30 days ago

- In-Disk: Redis Auto-Tiering Memory/Disk combination

- In-Disk: Postgres

> 30 days ago

- Object Storage: Backblaze B2

Most my personal and side-business projects have very spiky load or just low load in general. Because of that I love using AWS Lambda as my backend since it scales to 0 and scales to whatever you have your limits set at.

I use SST [0] for my backend with NodeJS (TypeScript) and Vue (Quasar) for my frontend. For my database I use either Postgres or DynamoDB if the fit is right (Single Table Design is really neat). For Postgres I like Neon [1] though their recent pricing changes make it less appealing.

[0] https://sst.dev

[1] https://neon.tech