29

I've seen that V2 is out now but there is no option to have the data api and the docs say it is only available on V1.

The Data API can be enabled for Aurora Serverless v1 DB clusters using specific Aurora MySQL and Aurora PostgreSQL versions only. For more information, see Data API for Aurora Serverless v1.

Has anyone seen any comms to when it may be out?

Maurice
  • 11,482
  • 2
  • 25
  • 45
Angelo Mermiklis
  • 317
  • 1
  • 3
  • 4
  • 1
    This website isn't AWS support. Also Amazon doesn't usually publish timelines for features. You need to ask your Amazon account rep this sort of question. – Mark B May 13 '22 at 14:38
  • 2
    Typical SO response. People seem to take more pride in being condescending than helpful. Oh well, AI will replace this site soon and folks will have to direct their ire elsewhere for entertainment and validation, I guess. An appropriate response would have been: "Your best course of action would be to ask your AWS account rep. They would be the most likely to have information on feature timelines, etc." – chad Apr 06 '23 at 14:14

3 Answers3

33

It's kind of idiotic of AWS to not include the Data-API in Aurora Serverless v2 as there are many customers who jumped on v1 and have connected it to AWS AppSync as a resolver.

With v2 this is no longer an option and we are stuck on v1 (with its crappy scaling), or presented with the option to add Lambda as resolvers, which not only takes time to develop, but also adds latency and maintenance to the solution.

I've raised several request for adding Data-API to v2 through AWS support, that's the only thing we can do, and please flood them with requests!

AWS architects or customer contacts have no information to provide on the subject at this point in time.

EDIT 2022-10-17: I have received word today from an AWS resource with some insight and it doesn't bode well as it seems the Aurora team, though very aware of the problem, are not planning to add the Data-API anytime in the near future, if ever. It is not a planned feature for v2 (nor v3, as that is on the drawing board, apparently) which would mean that it is not happening within the next 6 months at least... Please note that this is my "belief" after piecing together the information I have received!

We will start looking into our alternatives and Aurora Serverless might not be the best choice for us...

Anders
  • 3,198
  • 1
  • 20
  • 43
  • 1
    Is there any other way to use it effectively with AWS Lambda? – eL_Finito Jul 19 '22 at 12:08
  • 1
    @eL_Finito You may try RDS Proxy, but that kind of defeats the whole purpose of going serverless. – Vicary Jul 26 '22 at 11:58
  • The Lambda for AppSync is fairly fast, the tests we've done is that we loose about 30% compared to the Data-API when using Node.js Lambda with knex. – Anders Aug 05 '22 at 04:50
  • We have an AWS Support plan and today we raised a Support Request about Data API availability in Aurora Serverless v2. Will update here once we get a response. – marracuene Jan 07 '23 at 11:56
  • AWS responded, below is the relevant bit of their response. So @Anders recommendation "please flood them with requests" looks like best option for now. **we currently don't support Data API for Aurora Serverless v2 at the moment. We've added this request to our backlog but unfortunately we don't have a time frame for when it will be implemented. We take feature requests from our customers seriously as we engineer improvements based on customer feedback rather than what we think customers would need. In order to expedite the feature request I have linked your case to the feature request.** – marracuene Jan 07 '23 at 13:06
  • 1
    Here is a publcly-available confirmation that a Feature Request for Data API on v2 does exist: https://repost.aws/questions/QUc6tQ-_TsRWeSXAxSlqTPEg/is-data-api-for-aurora-v-2-v-3-planned Would be great if everyone could upvote the post to give it some more visibility to AWS roadmap planners . – marracuene Jan 07 '23 at 15:10
7

As per official docs:

The Data API and query editor aren't supported for Aurora Serverless v2.

Also confirmed again with clearer wording:

The Data Service API isn't supported on Amazon Aurora Serverless v2 DB clusters.

Ermiya Eskandary
  • 15,323
  • 3
  • 31
  • 44
  • Do we have any information from AWS on this? What might be the possible solution if they are not releasing DATA API? What about the current implementations done by customers? – kiri Aug 02 '22 at 11:46
  • @kiri No information yet - the solution would be to stick to V1 ultimately. V1 is still supported so current implementations are not affected. – Ermiya Eskandary Aug 02 '22 at 12:52
  • heard v1 will be deprecated by Feb 2023 so thinking of alternative options. – kiri Aug 03 '22 at 13:04
  • 1
    It's only MySql version being sunsetted https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html – Anders Aug 08 '22 at 19:19
  • To add on to @Anders comment, MySql v1 is being sunsetted which has no correlation to Serverless v1 – AndrewL Sep 20 '22 at 22:20
  • And they just updated the statement, `This document was last published on September 27, 2022`, that v2 won't have the Data-API... Well, what do we do with our AppSync VTL's now as v1 scaling is an utter failure... :( – Anders Sep 28 '22 at 08:08
  • 1
    @Anders Correct - I confirmed with the internal AWS team. They may change their mind if there are enough requests for it, so I would advise suggesting it to AWS support / your TAM / your SA. It's unfortunate. – Ermiya Eskandary Sep 28 '22 at 08:52
  • 2
    We have five AWS accounts in total and I put in the request from all five, on different e-mail addresses... – Anders Sep 28 '22 at 08:58
7

This is significantly affecting us as well, and as of now (Dec 1, 2022), still no word on Data API. Also, per someone else's comment, Postgres v10 on Serverless v1 IS being force upgraded to Postgres v11 in Jan/Feb 2023. We've received multiple notices of it. Unfortunately for us, this comes with an update to Postgis v3.1, which is a dramatic performance decrease in our usage (vs. Postgres v10 + PostGIS 2.4 that we have now). We've done tests, and basically it destroys our ability to use it (went from sub-second query times, to some queries taking nearly a minute!).

So, our only path at this point is to move to Serverless v2, which allows Postgres v13 or v14 (we'll go straight to v14.5), which does NOT have the performance problems we saw with v11. But, we were fully using the Data API, so not only do we have to deal with that, but it means putting all our Lambdas back into a VPC, incurring the NAT Gateway cost (minor in the grand scheme for us, but could play for others), and of course just the higher complexity of all that.

I find this very disappointing on AWS' part - that they want everyone to move to Serverless v2, but they didn't create feature parity (Data API). I welcome the ability to move to a much newer version of Postgres, but am very bummed about the lack of Data API and the VPC requirement, etc.

chrisrbailey
  • 2,220
  • 1
  • 20
  • 13
  • A few months ago were 'force-upgraded' from PostGIS 2.4 to 3.1 (while still on Postgres 10) because we needed to create a new cluster, and the minimum Postgis version for new clusters was bumped up to 3.1. So we had to upgrade our whole stack. We didn't notice adverse performance, however we use a pretty small subset of the whole Postgis feature set. We are now preparing to upgrade to PG 11 given that PG 10 is sunsetting at end Jan. I'll update here if we find that PG11+PostGIS3.1 has different performance from PG10+PostGIS3.1 – marracuene Jan 07 '23 at 11:14
  • 1
    I have now completed our transition from Serverless v1 with the Data API to Serverless v2 with a SQL connection (and moving our Lambdas back into a VPC). This all actually went quite smoothly. So far, performance is great, and we're using less ACUs with Serverless v2 (so while it's 2x as expensive, we're using considerably less, and see it scale a lot faster up and down, so will likely cost us less). – chrisrbailey Jan 09 '23 at 20:48
  • 1
    @marracuene great to hear you don't have the performance issues. For us it was totally random - some performance was the usual fast (ms query times), but some - same exact query to the same table, just a different location, took almost a minute! This performance issue we ran into was also on a reasonably large DB (3-4TB), so we thought that might play in, but so far all good now on Postgres 14.5. – chrisrbailey Jan 09 '23 at 20:52
  • if I may ask a supplementary question (strictly speaking should be a separate issue, but easier to keep all this in one place). How do you achieve performant connection opening in v2? Each Lambda opens a fresh connection to RDSProxy every time it receives an Invoke? – marracuene Jan 13 '23 at 11:04
  • 1
    @marracuene RDS Proxy itself is supposed to be more of a consistent connection that deals with this. We aren't using RDS Proxy yet, but plan to switch, as it is suggested as a best practice when using RDS/Aurora from Lambdas. That said, depending on your lambda functions, you can create the DB connection when the lambda is initialized, and hold that (we use Go, so doing this in the init() handles it - I don't know about for other languages, but have seen mention of it). So, at least in that case, you only connect essentially on a cold start. – chrisrbailey Jan 14 '23 at 20:11