- mysql 5.7 compatibility
- acting as replication master or slave
- faster upscaling, more likes 5s instead of 30s
- publicly accessible over internet (the rest of RDS has this)
- aurora parallel query built in
- aurora multi master built in
Basically, I asked for one product to merge all their interesting features. That sounds nice and like a one-size-fits all database. I would very much like to use it in production. It would require very little maintenance.
It looks like by enabling Data API, you expose that endpoint to the entire internet - which is secured like all the other AWS services with HTTPS, IAM, etc.
having said that, i'm actually pretty happy with dynamodb...so far.
Aurora is already pretty good at handling a lot of connections but this is even better.
But the real problem was connection time was unusable for any client facing application. I tried it after it was released (not preview). I really doubt this API would respond any faster.
Although admittedly if Lambda scales to multiple JVMs as request rate increases, you'll have multiple pools. Or if your request rate is low you'll not get much benefit
Does anyone have performance feedback now that it is no longer beta?
That said, I don't know how Jeremy Daly got away with making that post, per AWS preview terms. They are pretty explicit about not posting benchmarks on their preview products, and that makes sense as the API is not stable at all.
Still, I'm glad to see the data and hope that the performance has improved. I wasn't accepted into the preview, and I've started work now to move most of our infrastructure to GCP. It notably does not require any fancy footwork to have a Cloud Function talk to a Cloud SQL instance https://cloud.google.com/functions/docs/sql#overview
Think of a spike in traffic, 100 functions connect one connection per function. Then a break 80 of them go cold. Your max connections is 100, so if 80 didn’t disconnect and are waiting to timeout you are stuck. Any more functions coming online won’t have any connections.
The only work around in AWS was to setup an external connection pool, kind of begins to kill the serverless savings and all.
- Lots of improvements & better documentation
- Smaller response size, but can be cut down a lot more
- Sub 100ms query performance
> I’m really impressed by the updates that have been made. I do want to reiterate that this isn’t an easy problem to solve, so I think the strides they’ve made are quite good. I’m not sure how connection management works under the hood, so I’ll likely need to experiment with that a bit to measure concurrent connection performance.
edit: formatting
Things establishing new connections will never be as fast as things reusing existing connections. It seems wasteful to ignore this.
Also, establishing an HTTP connection is much faster than establishing a typical database connection, in my experience. I don't know why that is.
That’s the main selling point to me, though the connection pooling of MYSQL connections by the HTTPS proxy is also nice too.
