nikita

It’s mostly a region question. If the data centers are physically close to each other latencies will be low as well: https://neon.tech/blog/sub-10ms-postgres-queries-for-vercel-...

Price/performance will be a wash at least for steady workloads.

But usability will be massively better. Both platforms offer various things to make developer more efficient and dev cycle shorter

Yes of course. People do it all the time.

For small workloads egress cost doesn’t matter. For larger - well it does.

I wish it was illegal to charge so much for egress for cloud providers.

Ah, it is whatever AWS calls vCPU. Virtual core in an EC2 instance

Compute size is measured in CUs. 1CU is 1vCPU and 4GiB of RAM. Database compute and it's read replicas autoscale from 0.25 to 10 CU based on load and down to zero when inactive.

And autoscaling works like this: https://neon.tech/docs/introduction/autoscaling

Neon CEO:

Storage is will be long term unlimited. Short term it is few terabytes - we are constantly increasing the ceiling as storage sharding improves: https://neon.tech/blog/how-we-scale-an-open-source-multi-ten...

Compute autoscales from 0 to 10CPUs per read replica with 0.25 CPU increments - you set up min and max. We give our enterprise customers larger compute sizes. And you can have A LOT of read replicas that stand up instantly.

It's full compatibility with libpq Postgres protocol vs performance. Libpq is chatty and therefore you incur roundtrip costs. HTTP Post is one shot, but you lose transactional semantics if you don't provide all the queries in the same POST request.

We will consider it in the future. The important property in sharding should be the ability to go up and down in the number of shards. Each shard will increase write throughput and we should allow to go from 1 shard (default) to N to M and back to 1. This way we don't have an "upgrade" problem that Citus has.

Please say more of what you would change in the README and we will update

We debated internally if we wanted to provide MySQL too. On one hand it’s not that different and our storage can be adapted to run MySQL.

On the other hand focus and product identity are very important for startups. So it’s only Postgres

I'm CEO at Neon. We are very excited to partner with Microsoft. Happy to answer questions!

(Neon CEO)

What makes it not serverless in your opinion? This is our architecuture: https://neon.tech/docs/introduction/architecture-overview and no, you can not get the same from CloudSQL.

Neon CEO

Happy to answer any questions here. We hope we will make this happen some time

(Neon CEO) We could consider that. Right now we are exploring to actually run the app in the same or next to the micro-VM that runs Postgres.

https://neon.tech/docs/introduction/architecture-overview

(CEO of Neon.tech)

Aurora is one of the few real innovations in the database space recognized by SIGMOD: https://sigmod.org/sigmod-awards/citations/2019-sigmod-syste...

It provides a lot of benefits to the user and also a ton more to the service provider. Specifically you don’t overprovision storage or compute. Plus at least theoretically you can provide invite IO throughput at the storage level.

There has been a couple more iterations on the design since. Microsoft separated transaction log from storage: https://www.microsoft.com/en-us/research/uploads/prod/2019/0...

Neon added an object store and branches so you can integrate backups and add a Time Machine.

PolarDB separated memory from compute - this makes serverless compute more nimble and unties memory and CPU.

Postgres is missing a proper columnstore implementation. It's a big gap and it's not easy to build.

One solution could be integrating duckdb in a similar way as pgvector. You need to map duckdb storage to Postgres storage and reuse duckdb query processor. I believe it's the fastest way to get Postgres to have competitive columnstores.

I have another question. So far on the clickbench leaderboard it's 15x slower than baseline. The number 1 place is 1.67 slower the baseline.

I assume that's DataFusion speed. What's the plan to improve upon it?

It looks like hyper scalers can still host it as long as they are publishing changes to the source code ? Am I reading the license right ?

This is great work! Could you please comment on the choice of your license. Lost Postgres extension that achieve wide adoption use Postgres, MIT or Apache license.

I believe you had to opt in and it has some legal language before it. All the data pages were stripped and SQL Servers stores all data in the buffer pool. But of course you could find some stuff on the stack and other caches.

Microsoft is really good at this BTW. At SQL Server we had mini dumps they were tiny stripped out of personal info and incredibly useful. And a full dump of a production SQL Server even at that time (15 years ago) would be a huge file - too big to move around.

(Neon CEO) I'm sorry you had this experience. We had several instabilities in Q4 as the system became popular. That was the one of the reasons we called it "preview" until we got stability to where it needs to be. We are also very transparent about every outage - see neonstatus.com and highlight even the smallest ones.

We are also iterating over prices - we were purely consumption before and realized that we need to offer $19 pain plan to start based on the value our customers get. This is in line for what other devplatform charge for using their services.

Postgres \ commands are incredible shortcuts that are a pain to write in sql. E.g.

\dt+ translates to

SELECT schemaname, tablename, tableowner, tablespace, pg_size_pretty(pg_total_relation_size(quote_ident(schemaname) || '.' || quote_ident(tablename))) AS total_size FROM pg_tables ORDER BY pg_total_relation_size(quote_ident(schemaname) || '.' || quote_ident(tablename)) DESC;

When Neon goes down twitter lights up, we haven't had it for a long time now.

Internally we are measuring the number of projects under 5 min in the last 30 days and it's been lower double digits over 700K+ total databases under management.

A TON of effort is going there, twice a week standups, tightening our processes and quality across the board, a standing item in our monthly board meetings. While stability is black and white, what goes into delivering it is a long tail of small and large improvement and a major team effort.

We will also update the status page soon.

Merging is a tricky one for operational databases. We think merging schemas is a useful feature. Merging data is likely not. The feature is coming!

You will likely save money on Neon. Please reach out to our team (contact sales, support or discord) and we will give you an estimate

We are currently lumping storage retention history (we store all the history for a period of time so you can time travel) and backups together.

We are rethinking this, please stay tuned

Yes :)

Please join our discord a number of people are doing that and the community is helping out.

(Neon ceo)

Our storage tech is amazing :)

And written in Rust for extra fun and profit