Very interesting, tempted to apply to the company as this sounds very promising and fun to work on...<p>I'm curious about the business side of things, to give some context, some open source models that startups use today are:<p>1. The "open core" model, Gitlab being a good example. They try to split features that are open or closed/enterprise depending on the buyer.<p>2. The AGPL model, Mongodb used to do this, today a popular example is Grafana and their collection of products.<p>3. The Apache + cloud backend model, the core being standalone working with Apache license while building a value added managed service. I think this is what Synadia is doing with NATS.<p>4. The "source available" model, not really open source, but worth mentioning as it's very popular recently. Examples Mongodb, Elastic, Cochroachdb and TimescaleDB. This is often combined with open source such that some parts are open source, others source available.<p>With this as a reference Nikita, how would you explain how Neon thinks in regards to licensing and eventually building a healthy business? It's obvious a managed database service is the money maker, but how do you think around compeditors taking the project and building managed services without or with minimal code contributions? I'm sure you guys have thought a lot about this, would be interesting to hear some thoughts and reasoning for or against different options.<p>(Note: This is not meant to be an extensive explanation of these business models just a high level overview. If I have miscategorized some company above feel free to correct me in a comment.)
Are there plans to release an HTTP API to make it easier to use with services like Fastly Compute@Edge and Cloudflare Workers? And if so would the API be global or region specific?<p>One thing I haven't seen with "serverless" databases is an easy way to dictate where data is stored. Mongo has a pretty clever mechanism in their global clusters to specify which regions/nodes/tags a document is stored in, and then you simply specify you want to connect to nearest cluster. Assuming your compute is only dealing with documents in the same region as the incoming request, this ends up working really well where you have a single, multi-region db, but in practice reads/writes go to the nearest node if the data model is planned accordingly.<p>A real world example of how I am using this in Mongo today: I run automated trading software that is deployed to many AWS regions, in order to trade as close to the respective exchange as possible. I tag each order, trade, position, etc. with the exchange region that it belongs to and I get really fast reads and writes because those documents are going to the closest node in same AWS region. The big win here is this is a single cluster, so my admin dashboard can still easily just connect to one cluster and query across all of these regions without changing any application code. Of course these admin/analytics queries are slower but absolutely worth the trade off.
Looks like it's already released as FOSS. Stellar!<p><a href="https://github.com/neondatabase/neon" rel="nofollow">https://github.com/neondatabase/neon</a>
Depending on the cost per database, a service like this could allow one to build SAAS apps with Single Tenant model [1] in a really simple and elegant way.<p>I always liked this model since it gives the best isolation and not having to code with multi-tenant in mind really simplifies development and security. But maintaing an infra for this is hard and costly.<p>[1] <a href="https://docs.microsoft.com/en-us/azure/architecture/isv/application-tenancy#single-tenant" rel="nofollow">https://docs.microsoft.com/en-us/azure/architecture/isv/appl...</a>
Looks awesome.<p>How does the memory cache work? The architecture looks great, but so much of PG efficiency is cache hit rate. Do the pageservers have a distribution plan? Plans to add something like DynamoDB Accelerator?
We are using AWS Aurora (non serverless) and getting crushed by IOPS charges. We do very little caching in our app, which makes the architecture simple, but the downside is we end up relying on DB-level caching implicitly. And so when the DB instance has enough memory, IOPS are modest. But once we outgrown it, we have to scale compute up just to get more RAM or else we get destroyed on IOPS.<p>Seems like from a cost standpoint Neon does a good job of avoiding EBS entirely and thus this particular problem would be sidestepped. Is that right?
Sounds very exciting, but curious about performance. Of course there will be downsides, it would be nice if this could be characterized somehow as part of the docs or site.
Congrats on the launch! Does it support logical decoding plug-ins? I.e. could I use for instance Debezium for streaming changes out of Neon to Kafka etc.?
>EBS volumes are very expensive, AWS throttle your throughput unless you pay for provisioned IOPs<p>How does using local SSD instead of default EBS help achieve higher throughput though? I get it's cheaper and lower latency but I fail to see how the rebalance magic solves the throughput tradeoff for all unless they throw more ram at it.
I'm not familiar with postgres or cloud architectures and I have a few dumb questions. Is the pageserver act as a page cache for s3? Does the postgres compute also have an internal cache? If so, this looks like multiple levels of memory cache connected by networks.
What sort cold start times do you hope to achieve? If it's serverless and no cost while not using(aka scale to zero), you can't run those containers all the time. For comparison the serverless version of sql azure takes ~50 seconds to cold start.
How long before we get public access? I signed up for the beta a few weeks ago but I haven't heard back aside from having to fill in a bunch of surveys.