CFrame (AKA CoordinateFrame) values are used to store rotational (In a 3-by-3 rotation matrix that stores values in radians.) and positional data, for example BasePart.CFrame for storing a BasePart's position and rotation, ect.

While Vector3 values stores 3 dimensional vectors that can be used to store a variety of things, like BasePart.Orientation for rotational data in Taitâ€“Bryan angles format, BasePart.Position for positional data in a WorldRoot, BodyPosition.MaxForce for setting a limit on how much force can BodyPosition apply on each axis, ect.

It stores values in a 4x3 unit matrix actually, and not as radians. Using a matrix for rotation means that each pairing of numbers in the matrix is a vector. You have three perpendicular vectors to describe rotation and one vector to describe position.

1, 0, 0, 0
0, 1, 0, 0
0, 0, 1, 0

Going in columns, you have the right vector, top vector, back vector, and position.

This could be a 4x4 matrix and function fine with standard matrix transformations, but thatâ€™s not necessary for Roblox. Roblox has CFrames coded to function with a 3x3+position

in fact, internally it is 4x4 because it is a lookat matrix! itâ€™s just that the components we can change are only accesible in those component fields

Youâ€™ll need to educate me then. I thought for certain that the bottom row was garbage and wasnâ€™t stored anywhere. Their functions for sure only apply a 3x3+position transform, not a true 4x4.
Specifically, I have no idea what is or what makes it a lookat matrix.

Can you show me a post or an article that says that CFrames are LookAt matrices? Because I canâ€™t find a single post that mentions it and looking at a XML Roblox file shows that no such 4th row exist in saving process. Only x, y, z, R00, R01, R02, R10, R11, R12, R20, R21 and R22 values are stored as shown by this screenshot here (and I doubt this is much different in binary file format):

The only way that LookAt values can exist is that they are created at some point in runtime, which kind of defeats the point to make it a 4x4 matrix if youâ€™re not going to save the entire matrix in the first place.

Moving on to @JarodOfOrbiterâ€™s reply, yes, youâ€™re technically not wrong on the fact that it kind of acts like 4x3 Matrix. However, I probably shouldâ€™ve worded my sentence a bit better because I was only talking about the rotational part of the matrix at that part of the sentence, hence I typed this:

I added the positional data part after I said the â€śIn a 3-by-3 rotation matrix that stores values in radians.â€ť part to make it more clear that Iâ€™m only talking about the rotational data part of the CFrame values, though I shouldâ€™ve worded it like this:

An another note:

While yeah, rotational values might be stored as Vector3s in runtime and as separate numbers in file, numbers stored on those values are still treated and saved to be used as radians later so my point still stands.

Anyways, thatâ€™s all I have to say in this matter.

When trying to scale a parts CFrame it resets its position while changing its size with Vector3 doesnâ€™t. CFrame also can be used for rotation but itâ€™s the same, changing itâ€™s orientation with Vetcor3 doesnâ€™t reset anything.

well thats just from my experience coding computer graphics stuff. its clear that cframe is a lookat matrix. the lookvector, upvector and rightvector describe the rotation and the position is where the lookat matrix is at. check this out, its common sense