I feel like the choice of the name "serverless" is unnecessarily confusing/controversial, but I like the concept.<p>The ability to scale down to zero could certainly be useful for automated testing use cases.<p>As with anything on AWS it will take some testing to discover all the quirks and caveats, but I like the general direction this is headed.
This really is a new paradigm shift for relational databases. In general, on the DB side, you are not able to scale horizontally like application tier. So for the fear of degradation of service, most of us end up overprovisioning on the DB side. With Serverless, auto-scaling Aurora, I think things will change for the DB tier too.<p>The Serverless section in Aurora FAQ [1] is also worth reading. The main gotcha I think is:<p>>> Q: Why isn't my Aurora Serverless DB Cluster automatically scaling?<p>>> Once a scaling operation is initiated, Aurora Serverless attempts to find a scaling point, which is is a point in time at which the database can safely complete scaling. Aurora Serverless might not be able to find a scaling point if you have long-running queries or transactions in progress, or temporary tables or table locks in use.<p>So I think one will need to focus on quick OLTP type queries.<p>Still, I am quite excited to see how this shapes up.<p>[1]: <a href="https://aws.amazon.com/rds/aurora/faqs/" rel="nofollow">https://aws.amazon.com/rds/aurora/faqs/</a>
This is extremely frustrating. One of the biggest use cases for wanting to use Aurora serverless is connecting to MySQL using lambda functions -- Function as a Service apps that can still use rdbms. The problem is that RDS endpoints only exist inside vpcs, and cold starting a lambda function with a vpc network interface can take 10+ seconds, making it useless for an API.
I had hoped that, given they were making a serverless MySQL service, they'd make sure it actually plays well with lambda. Nope. Same problems regular RDS has. No better method of securing the connection beyond vpc firewall rules.
Amazon, it's been a problem since lambda was launched and it hasn't been fixed. Either fix lambda vpc cold start times, or provide a better way to connect lambda to RDS. Just burying the problem only pisses off your customers when they try to buy into your hype.<p>And since it always comes up:<p>* Yes, there is plenty of reason to want to use MySQL with lambda. Wanting to run software on FaaS does not mean wanting to abandon rdbms. For a small app, dynamodb is overkill; for a small app that turns into a large app, dynamodb is a money pit.<p>* No, adding scheduled heartbeat requests to the lambda functions so they never have to cold start is not a real, long term, scalable solution. It's a hack, it doesn't solve the problem if your app actually scales up, and infrastructure shouldn't depend on horrible hacks to function correctly.
Assuming this hasn't changed since the preview started:<p>> The cool down period for scale-down is 15 minutes since the last scaling operation. The cool down period for scale-up is 5 minutes since the last scaling operation.
I have to say, it's really frustrating that Postgres is a second class citizen in the AWS ecosystem. Aurora in general is often far behind on Postgres support relative to MySQL. I hope this changes going forward.
> <i>Pay only for the database resources you consume, on a per-second basis.</i><p>> <i>You pay a flat rate per second of ACU usage, with a minimum of 5 minutes of usage each time the database is activated.</i><p>Cool idea, but an IO operation once every 5 minutes is considered (billing-wise) a full time service.<p>This could unlock a lot of cool potential if it had finer granularity. I can think of some IoT applications that have have infrequent operations which would be cost effective with less minimum time.
I had assumed that this would be a HTTPS service with a public end-point, available outside a VPC. But, looks like it is still deployed inside the VPC and accessible over JDBC. Did anyone find any configuration option to deploy it outside VPC? Overall, it looks like good old Aurora RDS with an auto start/stop option, and costing based on that start/stop duration.
AWS, why not PostgreSQL?<p>The bare minimum cost for Aurora PostgreSQL is $200/month. Aurora MySQL is an order of magnitude less.<p>Why not PostgreSQL?
Very exciting! I made a simple bot to scrape lunch specials menus off Instagram and post them to my company's slack (<a href="http://blog.matthewbrunelle.com/projects/2018/05/07/Soup-Bot.html" rel="nofollow">http://blog.matthewbrunelle.com/projects/2018/05/07/Soup-Bot...</a>).<p>One point point was making custom lambas to spin up/down the DB and everything that was needed to use it (a NAT on EC2, and an elastic IP since the default NAT aww provides is pricey). The bot only needs to run for an hour on weekdays so there's no point keeping everything running 24/7. Excited to try replacing all of that with this!
This definitely works from a cost pov. We use a small instance of AWS Aurora which is mostly idle. If we go this route we will need to see how quick the cold-start is and how quick the ACU scaling is. Serverless SQL DB - definitely a nice way to to go.
I'm excited for this. I have a few small, low budget projects that would either require expensive RDS instances or awkward data management to force the use of Dynamo. Now there appears to be a low cost SQL solution for serverless projects.