Hmmmm, I think I see where you’re coming from. I too hit this hurdle once upon a time.
takes a deep breath Hoo boy! Here we go 
You need to bring your formulas into “game space” and away from “math space”. Where “math space” defines each dimension in relation to each other. So, X is defined using Y, and Y is defined using X.
x=y^2 is a great equation and all, but in game space you need to introduce a key variable… time. You then need to solve for each of your variables with respect to time, and not necessarily in relation to each other.
Where is X at time t? Where then is Y at time t? Figure that out and you’ve already got your game space formulas!
For example, let’s take your x=y^2 formula. This is a “math space” formula because it defines both dimensions with respect to each other. We don’t want that! We want each one individually with respect to time! This makes a nice parabola, but it’s only defining the path.
That’s step 1, check!
From there we assume that our object will be moving along the path starting at the origin. This tells us that at t=0, both X and Y should also be 0. But what about at t=1? Well, we need to introduce time into the equation to find out! This is where we must make a conscious decision, because our path is split into the positive and negative directions. We could make this dependent on something, or choose one explicitly. We could make it depend on the side of the screen you’re on 
I’ll carry on assuming we’re going with the positive direction. I want to say that for my game, it makes the most sense that after 1 second, the projectile will be at x=1 and y=1. Great! Now after 2 seconds, the projectile should be at x=2 and y=Sqrt(2). That is the trend I want to follow, because it matches our original equation. For this to be true, then x=t must be true. That’s pretty simple! X formula, check! For that to be true, then y=Sqrt(t) must also be true. Also pretty straight forward! Y formula, check!
We can then take those formulas and plug them straight into our game!
transform.x = Time.time;
transform.y = Math.sqrt(Time.time);
That’s seriously oversimplifying the code, but that’s the gist of where this is going. In more practical code you would capture the time at which the projectile was fired and use (Time.time - startTime) to find the projectile’s “current time”.
BUT!
All of that aside, I don’t think you want to take this approach! What this sort of implementation will do is only make you dependent upon a cold, hard, rigid math equation. That’s not cool. No body really wants to sit around and write up complicated curve equations so their objects can curve all badass-like in different scenarios! Especially not when there’s an easier approach
This comes back to my question of “Why is my projectile following this curve?”
In most games where projectiles follow a curve, it’s not because they are bound to hard y=x^2 “math space” equations. It’s most likely because they are moving due to their velocity and being accelerated. Even if the system isn’t using a full-on physics engine to handle it, fluid curves in object motion almost always means: the object is moving Vx amount every frame, and Vx is also changing. Hell, a boomerang is just accelerating toward its owner 9/10 times.
The actual path formulas for an object under the influence of multiple forces plus gravity is stupidly complicated! (Not to mention the horrible framerate from lots of Sqrt’s) It makes no sense for us to lay down a calculated path defining all dimensions in relation to one another as you would in math class. This is a video game! Video games don’t care about graphs unless the player has to care about the graphs too! They care about moments in time. Physics!
So, approach your desired curve from a “moment in time” perspective. What happens to my object “at this moment in time”?
I know what path the projectile should roughly take. Let’s put ourselves in the perspective of the projectile at time 0. The moment I am launched, I’m ejected to the side slightly as I accelerate forward! Deploy-Rocket-style! (I seriously brain storm like this, no joke) This means my “sideways motion” (we’ll say it’s X-velocity) needs to increase the moment I am launched. We call this “initial velocity”. However, I haven’t accelerated yet, so my “forward motion” (Y-velocity) should start out at 0.
Cool, initial velocity of (x=1, y=0) check!
After I’ve been launched, I accelerate straight forward! So every frame, my Y-velocity should increase by some amount. Now, I’m just a missile, so I’m not very good at maths, so we’ll just say I’m going to be moving 1 “velocity unit” faster, every second! – in the Y direction!
float forwardVelocity = 0.0f;
float sideVelocity = 1.0f;
...
void FixedUpdate()
{
forwardVelocity += 1 * Time.fixedDeltaTime; // fixedDeltaTime lets us scale our "every second" value of 1 down to what it should be for the amount of time that has actually passed. Only to be used inside of FixedUpdate
rigidbody.velocity.x = sideVelocity;
rigidbody.velocity.y = forwardVelocity;
}
I suppose we could put some “drag” on the X-velocity by constantly multiplying it with 0.5 or something.
But hopefully you get the picture.
This implementation achieves a similar curve as x=y^2, but no exponents or square roots to be found. It is more intuitively flexible. For example, you can change the steepness of the curve without having to dive into scaling your exponent, and which power are you even going to? Maybe this is a curve better suited for y^3? That doesn’t matter anymore, because the basic underlying IDEA of what the projectile should be doing has been defined and is being followed, despite circumstance!
