Joran Dirk Greef: But if something’s open source, we’ll then reconnect it. And there’s lots of – just like people would pay Amazon for Aurora, because there’s a great value in all the management around Postgres… Again, porridge is too hot or cold. So we’d be curious to get your thoughts once you’ve thought about it, and I can sharpen the argument… Because I really think we need more founders need to stand up… And we’ve all been given a lot from the previous generation of open source, and I think it would be great if we all say “Okay, we’re gonna pay it forward as well. Make a technical contribution.” There’s no reason not to. I think it’s better for business, actually.

Anurag Goel: Yeah. You have to support it, you have to figure out how to deal with pricing, you have to make sure it works with the rest of your stack, your API surface area, your infrastructure as code, your whatever, your SDKs… You just have to keep doing that work over and over again as soon as you build something. And so we’re very careful about what we take on. But I think one of the things that we’re going to be able to do this year is take on more interesting stuff that I talked about, and even more than that. And that’s what I’m excited about, just allowing people to use Render in new ways, and also continuing to help people scale.

Our managed Postgres has come a long way… So this was another thing that we were pretty far behind Heroku on, and now we’re actually better than them, and they’re switching over to Aurora, saying “Oh, we’re not going to build our own Postgres anymore.” It’s just like “Alright… Well, that’s your call.”

And I think for us, it goes back to the experience, right? So if you try to build a wrapper over Aurora, then you’re a wrapper over Aurora, and you have to deal with their vagaries. And Aurora is not even Postgres-Postgres. It’s Postgres-compatible, but there will be stuff in your function code or your triggers that just won’t work the same way. And all the documentation online is for Postgres. It’s not necessarily for how Postgres on Aurora works.

And so I think the other thing that we’ve been lucky about is Heroku has made our job easier. It has helped drive people into our arms. And that was the other thing that happened when they killed their free tier back in 2022… That was when a lot of people first discovered Render. And it was not just that our free tier took off after that, it was also that our revenue took off after Heroku killed off their free tier… Which is just a [unintelligible 01:41:55.11] I’d say.

Pete Naylor: And this is another little shift that I know is going to be interesting for Justin, because I’ve seen some of the things that he’s been posting, and… You know, when I was an SA, while I saw what really worked super-well for Amazon and for a lot of other bigger companies or whatever, there was always this push to say “Well, it’s all about being on the cloud, and you only need one cloud”, and all of those kinds of things. And in some ways it was easy to believe. But over time, I just realized that no, there are like different scenarios, different companies… Certain products that when you scale to a certain point, then maybe it’s something you consider running yourself… There is this whole other reality around needing to still run things on prem. People need databases on submarines. They’re not connected. You need to run truly air-gapped. So there’s very real use cases and reasons, I think, to still be able to run where you want to… And I just think having flexibility around that is great.

[00:49:53.10] So a lot of the stuff that we’re working on at the moment is trying to give people flexibility around where you actually want to run this stuff, and have a nice experience that’s easy everywhere. One of the things that I saw at AWS was - there was DynamoDB, there was Aurora, and some of these things… But over the years, the number of these purpose-built databases just kept growing and growing, and it got more and more difficult to try and tease them apart and explain to people which you should choose.

Jerod Santo: Pretty cool. This is the biggest React conference in the United States, taking place in New York, on November 19th.

Now, this is a back-to-back conference by the same organizers that do JS Nation US, which I believe is happening November 18th. So there’s back-to-back conferences… We’ll probably be at both. We’ll definitely be at React Summit US on the 19th. We will have a booth, Kball will be there, Nick will be there… All of your standard JS luminaries. Addy Osmani, Theo Brown, Michael Chan, Kent C. Dodds, Aurora Scharff. The list goes on. Kelly Vaughn… I could just keep reading these cool names, but I’ll stop there. Join us.

Autumn Nash: Yeah. Well, not just that, but some of the – I missed the SQL part in the last question, which would have told me that it was not Dynamo and it was like Aurora or one of those, but… I don’t know. I feel like some of these are very general, and they can be multiple things… But yeah, that’s definitely Postgres.

Minko Gechev: Yeah, HTTP Archive Open Dataset, which has the top many thousands of websites out there, and there is a crawling that happens I think about once a month - they measure the performance of each one of these targets, and also what technologies are they using on the page. And we are definitely – well, we are using it in many different ways. We’re first curious to see what are the top performance challenges that websites are facing, and figure out on what we should be focused on.

There is another team at Google called Aurora. Aurora also joined us for our session at Dev World [unintelligible 00:31:36.16] They’re constantly looking at HTTP Archive and trying to figure out different patterns and how they can optimize the web overall, all the different frameworks. So that’s one way… Another way is - on Angular we’re overall measuring the impact of the performance improvements that we’re making by looking at the HTTP Archive very often. It’s not very – HTTP Archive is good for certain things, for example measuring performance, but it also is biased towards specifically landing pages, which doesn’t necessarily represent the whole framework community too well. A lot of frameworks are being used for dashboards, let’s say, and they will not be present in there. Specifically for load time performance, this is where the HTTP Archive comes really handy.

Craig Kerstiens: Yeah, I think that spin down to zero is a fair one. And, that’s a great question. To me, I usually think of serverless as more of a business thing… Like, “Do you actually care that it spins down to zero, or you just don’t want to pay for it when it’s not in use?” I think you even look at that spin down to zero, and look at it in Aurora - there is no like zero-cost Aurora anymore. It’s now a minimum, like “Hey, we’ll idle it, but still, there’s a minimum budget account for your database.”

Nikita Shamgunov: But think about it the following way - from the VC standpoint, there is a market; it’s called the database market. That market has players, and those players have share. And that share is on dollars, and on usage. And then there’s – you can also measure share in terms of mindshare. So if you look at share of usage, Postgres is going up and up and up. So that’s data point number one. And earlier, I said out of the top five databases, Postgres is the only one that’s growing share.

The second thing is, within the database market there’s an on-prem market, and there’s a cloud market. And the cloud market is the much faster-growing market. That market is dominated by the cloud hyperscalers - by Amazon, Google, and Microsoft. There is only one public database company that’s relatively modern and relatively recent, and that’s MongoDB. There isn’t a public relational database company, and developers are increasingly choosing Postgres over MongoDB.

Another data point is AWS Aurora is a $3 billion run rate business, going into potentially four and a half, growing 50% year-on-year into the next year. And that’s MySQL, Postgres, and MongoDB. MongoDB is kind of fake. It’s built on top of Postgres, because MongoDB’s license prevents them from running MongoDB compute.

So all of those data points highlight that there are a lot of dollars in the cloud database market. Postgres as a matter of fact, in a way, it’s kind of like Linux. So it’s not like you can – you can’t own Postgres. That ship sailed. But can you have the best in the world Postgres cloud service? I think that’s an open question, and that’s what we’re going after. That’s really the pitch, it was that simple.

Gerhard Lazu: [25:46] So hang on, hang on… Before we go to the dynamic one, one thing which really helped me to visualize the static part better was, first of all, to understand what is a static resource. And you have a list of examples. You had, for example, database; an Aurora database would be an example of a static resource. Once you create it, you’re unlikely to delete it. I mean, it’s unlikely; it may happen, but hopefully not, right? Especially the database…

Paul Copplestone: So the holy grail really, I think the person or the company doing it the best would be AWS Aurora have the sort of serverless Postgres. It has a bunch of quirks as well. Really though – I mean, it’s very hard to bet against Postgres. They know that there are some limitations around this, and we work around a bunch of these limitations with our existing tooling. For example, one of the limitations is around connections, and it doesn’t scale so well if you’re doing serverless directly to the database. So you’ve gotta put a pg-puller in place, or something like that. We provide a puller for you. Or if you just use our APIs, the HTTP API, you don’t have any problems at all. So really, we’ve solved some of the problems of working with serverless and Postgres.

Then you’ve gotta ask, “Well, how can Postgres be serverless?” And this is the thing that really our business is going to gear up towards over the next few years. We’re going to make sure that we can help with these efforts, build out a cloud native Postgres. We don’t wanna have to run a fork of Postgres. If we do run a fork, it’ll be to upstream as much as we can. And there are a lot of companies that are going to be working on this. A lot of people are interested in this, of course. Everyone thinks there’s a lot of money in it from a commercial side, but even the open source contributors just know that it’s something that Postgres needs to get through.

So there’s a lot of stuff coming in this space… Pluggable storage is an interesting one. New storage engines for Postgres, fundamentally rewriting the storage engines to be distinct, ways of combining it with, say, other disk tools, maybe ZFS, things like these… So there are people working around it with clustering, and things. So that’s how we do it at the moment, but really, I’ve got no doubt, give it five years, Postgres will have some very cloud native functionality.

Evan Weaver: Yeah, there’s a slow trend away from that model. The thing that people really hang on to is the sense of transparency and trust they get from the open sourceness nature of the database, the portability, the idea that you can switch from one vendor to another is important to a lot of people. In reality, switching an operational database is painful no matter what, even if in theory – you know, going from one version of Postgres to another version has problems, let alone going to a completely different implementation, or from one cloud vendor to another. Everything people use in AWS RDS or Aurora - it’s heavily customized, to the point of being unrecognizable at this point, compared to the open source editions of the database… But people definitely still value those aspects of the open source experience, and occasionally they ask for it…

But I think as we move in particular to a wider variety of cloud databases composed around these standard and proprietary interfaces in particular, one of the things that we’re working on that we’re excited about is better ability to query the same data from different query languages in the same database. At that point you don’t care so much whether that particular implementation is open source, and we’ve found people value the time to market, the operational experience, the pricing and cost benefits, the unique capabilities a lot more than they value being able to fix their own bug, or being able to put the source code in a vault in case some data vendor goes away.

Adam Jacob: “I’m in. Good pitch.” You know? Whatever, it wasn’t hard. Whereas the initial creation of GitHub was quite hard. So the activation energy for competition is much lower than leading the pack. So if you’re Cockroach DB, what they believe they’re doing is protecting themselves from that low activation energy for the big Amazons, and all those guys. That’s a complete falsehood. The reality is those guys have giant hosted global databases already. And if Cockroach DB built a giant globally hosted database that’s so much better than theirs, and they can’t launch a Cockroach DB service, what that’s gonna do is not keep them out of your market. It just guarantees they’re gonna enter the market with not Cockroach DB. You’re just guaranteed that you’re gonna have to compete with that other database on a feature-for-feature basis… Whereas if they could take Cockroach DB and launch AWS, they couldn’t call it Cockroach DB. They’d have to call it AWS McLaren DB, and then they’d have to describe all the ways that it’s compatible with Cockroach, and they’d have to talk about the upstream, and everybody would know… They’d be like “What’s McLaren DB?” and you’d be like “Oh, it’s Cockroach, only on AWS.” They’d be like, “Oh, yeah.” And as soon as those words left your mouth, what you’re saying is “Cockroach DB is the thing I wanted, and I used the AWS thing because it was easy…” And if I’m Cockroach DB, that’s a much better competitive position than saying “I had to choose Cockroach DB Aurora.”

So that’s sort of how Cockroach has set it up. And I think you can do better by trusting that that community that you want would actually lift you up. The value of that thing would be stronger, and that you’re better at the product you created than anybody in the world will ever be. And so Cockroach DB - I’ve never used it. I love Postgres. I’m building all the System Initiative on Postgres. I looked at Cockroach for ten seconds; because as soon as I looked at it, I was like “Why am I gonna pay Cockroach DB money, when I could just run Aurora?” And that was it. That was the extent of my competitive analysis. Because I would need a feature that Cockroach gives me, that Aurora doesn’t, that kicks me over the line… And they didn’t have one.

Now, if it was open source and they gave me extra optionality, all of a sudden I might feel differently about it. I probably would have chosen Cockroach DB. I probably would have used their hosted service and not Aurora. But I didn’t, because they opted me out. They’ll never know that, because what do they care? There’s a big enough community of people who love Cockroach DB, they’re paying them money… They say “Why are we successful at getting this money?”, the answer is “Because I sell a product that’s valuable, for money.” So they’re gonna listen to this podcast and what they’re gonna say is “That guy is nuts. That’s not how it worked.” And they’re right, because they’ve made their choices, and it worked.

Gerhard Lazu: This was the beginning, right? Aurora, all those challenges, SQL-based single database, migrations were challenging, a couple of other things… So this was like, what - two years ago? Three years ago?

Kris Brandow: [01:08:06.02] I mean, I would prefer people just had boring names for things. Google’s Cloud - they have boring names for all of their stuff, whereas Amazon is just like… What’s that thing that was the meme on Twitter? AWS… I don’t remember what it was, but there was this thing that was like “That sounds like a perfectly legitimate Amazon product”, but it was just like massive ****post on Twitter of just like “I could just make up something.” And then it was a thing that people were talking about.

So if you are going to use fancy language, at least make it plain and simple and boring. Amazon is getting a little too overboard with their product names. They started out simple. I prefer EC2 and S3 to Aurora… Like, what does that have to do with databases?

Brad Van Vugt: Yeah. It’s a really natural progression, too. One of our team members, her name is Aurora, and she always says the first four steps of Battlesnake are like first of all don’t hit walls, don’t hit yourself, don’t hit other snakes, and then eventually try to find food. If you watch someone build a battlesnake for the first time, that’s always the steps they take, and it’s typically in that order as well.

So the challenge is kind of like us leaning into that a bit more; we’re starting to produce more content around how to achieve those first four steps. We’ve also thought about adding some more basic, some more base-level code to the projects that we publish. You mention that like – I think the Go Starter Project just moves randomly, but we could start adding maybe some helper functions to do distance calculations, [unintelligible 00:32:05.16] or this kind of thing. Not solve the problems for you, but give you some of the tools that you’re probably gonna wanna use. Still let you apply them.

Guillermo Rauch: I do think that the truth is somewhere in the middle, because for example a lot of the functions that we write at ZEIT for core systems are acting as glue sometimes between – they’re not fully us. Think of it as like writing assembly code versus writing a high-level language. We’re not necessarily always writing raw infrastructure inside those functions. We’re sometimes maybe invoking a bunch of API calls to Stripe to perform some sort of billing-related task. So the A, arguably, the heavy-lifting of the A is being done by Stripe, and we’re simply adding some more business logic on top.

Something that’s really cool about functions and I think doesn’t get discussed enough is that, for example with ZEIT functions, we allow you to say what region you wanna deploy them to, and we tell you “Well, this region maps to this AWS region, or it’s close to this Google Cloud region…” So say that your API provider, in this case, let’s say is Stripe; for your billing, charges, customers, whatever. And they’re in U.S. East, in the Virginia data center or around there. If you deploy your function far away from Stripe, if you’re making lots of API calls to Stripe to get a certain result, you’re gonna see very bad latency.

[36:29] You’re gonna see that your function takes multiple seconds to execute. However, if you deploy it right next to Stripe, it’s basically like functions are literally augmenting the Stripe codebase, because you’re literally deploying them to the same data center, and all of a sudden you go from like instead of a 90 millisecond roundtrip, you go to sub-millisecond, because it ends up being the same data center as the Stripe computers are in AWS.

So I see functions of this incredible, almost open plugin ecosystem for the world. I think longer-term we’re gonna be writing functions that do very little in terms of, like I said, that low-level infrastructure stuff, and it’s more like you’re just gonna be invoking different API providers. It’s happening a lot with databases. A lot of databases are moving to providing HTTP gateways for executing their payload… So it feels like when you’re talking to Aurora MySQL in AWS, it feels like you’re talking to just yet another RESTful API; only that it has more flexibility with regards to the queries that you send.

Tom Preston-Werner: My hope is that people never have to eject from RedwoodJS. I see it the same way as saying like “Would you ever eject from Rails?” It’s not a question that you would ask. And I know that that’s how Create React App is. But Create React App is very unopinionated. It’s a very base level of what you get. If you want anything on top of that very basic thing, you’re back to choosing technologies and trying to integrate them; and everyone does it in a different way, and then you’re like “I can’t do this one thing I really wanted to do, so now I’m gonna eject… And now I don’t get the benefit of being on top of a framework as such.”

We see RedwoodJS as a proper framework; something that is always with you, and that you always want with you, because it’s providing improvements forever. I think people will always need to be able to change the parameters a bit in how they deal with a framework. If it’s too rigid, then no one will use it, because they know that it can’t scale. That would be killer for a framework; people start using it, and then they build something and it gets popular and they’re like “We had to bail from RedwoodJS because it was too inflexible”, that’s very bad.

I think it’s also bad for a framework to be too flexible, where you’re like “Yeah, you can have any frontend. You can use React, or Vue, or Svelte, or whatever you want”, and you’re trying to cram everything together. Then the question is “What is this, and why is it helping me?” and can you really maintain a high level of integration with so many options? I don’t see it happening; it’s certainly not our intention for RedwoodJS to be super-flexible. We want it to be flexible in the ways that matter. So on the database side I want it to be very flexible.

[20:29] If at some point you want to CDN-deliver your React client, but run your own servers for your GraphQL API and all your business logic, then I think that’s fine, and RedwoodJS will be very amenable to that. So that’s a level of flexibility where you go away from serverless. You run the whole thing custom; you run it on your own CDN, you run it on your own hardware for your business logic to run your GraphQL API, you run your own database however you want… I want it to be able to run in that environment, but it’s also important to me that you can just deploy it to Netlify. It’s like “Oh, I had this idea, I coded it up, I pushed to Netlify, and it’s live. I had to set up my database right now.” I think over time that will become easier, too.

I’ve talked with the Netlify folks to hopefully make it easy to spin up simple databases through Heroku, or DigitalOcean, or something, so that you could do it without having to leave Netlify. It’d just be like “I need a database” and Netlify can be like “Cool. We’ve got it.” In the same way that they provision Lambda, they could provision – or AWS Aurora, or something. It’s like, “Give me an Aurora database, Postgres on this type of performance characteristics”, and it’s just like “Okay, here you go.” And if you need to change that later on, that’s a hassle… But companies go through that kind of migration all the time, where you need to change the capabilities of your storage layer.

Stevenson Jean-Pierre: [04:03] For me serverless is a combination of two things. For me it’s a lot of event-driven work; I consider it serverless when it’s driven by an action being taken, as opposed to constantly just being up and waiting for some kind of request to come in… That’s the compute side. But then you have even serverless technologies coming out on data storage, things like RDS Serverless or Aurora Serverless, so you can have compute, and it goes to Mat’s definition there, where you don’t have to worry about the underlying engine, you don’t have to worry about configuration… It’s just there and ready to scale when you need it to.

Jeremy Daly: There is certainly differentiation between AWS and IBM and the Google Cloud platform… But most of it is the same. The general idea is you write some code and you upload it into a function and it’s event-driven architecture - an event comes in, and that could be somebody uploads a file into an S3 bucket, or somebody posts something to an API Gateway, or there’s a message that comes in from a message bus, or something like that… Whatever those events are that come in, the basic idea of serverless is it’s a function that receives an event, does something with it, and then returns something back. Pretty much all implementations of it are the same in that regard.

Lambda, for example, was out in 2014 - way ahead of pretty much anybody else, so they’ve got a number of services that really complement it. You have their CloudWatch to easily log data; they’ve got their Simple Queue service, which allows you to do a message bus for queues. They have SNS, which is the ability to multi-cast events to multiple Lambdas or other locations, they have their Kinesis streams, and then they of course have Aurora Serverless and DynamoDB, which is their highly scalable serverless NoSQL database… So they have a lot more services that you can use in that regard. But then OpenWhisk, and Google Cloud Functions, and Microsoft Azure Functions they’re all very similar and they all have slightly different implementations; some of them run for longer…

Google Cloud Functions automatically has a built-in HTTP REST API, so that’s how you can access those functions, as well as access them through other events… But for the most part it’s pretty much the same, and there’s actually – and speaking of Serverless Inc., there is a committee out there that’s working to standardize events for serverless functions. That’s out there now, so hopefully that will kind of push all the providers to at least standardize the way that events are received, which I think would be a good point in consolidating the market.

Johannes Schickling: That’s almost right. For us, the focus on the monetization front is really where we see the biggest demand, and where we also see that we can build a substantial business, which is more on the enterprise side, since what we are building with Prisma as an infrastructure component is very similar to patterns that are already present in enterprise software systems.

[52:13] So if you think about it, Prisma and what Prisma enables - it really enables GraphQL as a universal query language. That’s very similar to what you had a decade ago with ODBC, so that idea is not new at all, and fits really well into an enterprise context, where additionally, through the data mapping part, you also have additional requirements, mostly around security and audit logging, various features around that. There are also many opportunities to just implement more efficient data-logging mechanisms, caching… So this is really what we are seeing a lot of demand for, where we’re working with bigger companies on an enterprise version of Prisma, and that’s really what we focus on from a monetization product perspective.

You’ve also mentioned Prisma Cloud, and what we see with Prisma Cloud is mostly sort of empowering developers with better workflows around databases, on the foundation that Prisma provides.

So you can think about Prisma Cloud kind of like as a database workflow platform. Over time, we’ll build various integrations with different cloud providers, where you actually host your Prisma server, where you host your database, so you could for example with Prisma Cloud connect to your AWS account where you run your database - let’s say an AWS Aurora - and you’re running your Prisma server on ECS or on Fargate, and you get all of the instrumentation inside Prisma Cloud… But more importantly, you get a lot of workflows around that.

We for example have a feature that’s called Data Browser. Think about that like – maybe you’ve seen Sequel Pro, PopSQL or think back to PHPMyAdmin…