Python 2, 63 bytes

from decimal import*
D=Decimal
x=input()
print cmp(D(`x`),D(x))

Try it online!

R, 50 bytes

f=\(x)(x>(y=sprintf("%.57g",as.numeric(x))))-(x<y)

Attempt This Online!

Function f returns

• 0 if the decimal representation is the same,
• 1 if larger,
• and -1 if smaller.

Anything beyond 57th decimal place won't be stored. If you put 0 on 57th decimal, you'll get 1 from f(), since technically 0.123...789 is laregr than 0.123...7890.

See the point about 57th decimal online.

Haskell, 33 bytes

compare=<<realToFrac.fromRational

Try it online!

Charcoal, 25 bytes

≔∧№θ.⌕⮌θ.η⁼∕ＮＸ·⁵η÷Ｉ⁻θ.Ｘ⁵η

Try it online! Link is to verbose version of code. Outputs a Charcoal boolean, i.e. - if the input can be represented in floating-point, nothing if not. Explanation:

≔∧№θ.⌕⮌θ.η

Find the number of decimals (if any).

⁼∕ＮＸ·⁵η÷Ｉ⁻θ.Ｘ⁵η

Divide the input by .5 to that power, which converts it to a float if it isn't one already, without further loss of precision, then compare that to the result of integer dividing the input without a decimal point by 5 to that power.

Maple, 44 bytes

s->sign(evalf[20]((r:=parse(s))-evalhf(r)));

Compares with hardware float type as internal representation. (Maple's default floats are decimal and so precluded by the rules.)

Inputs a string; output is -1 if the internal is greater, 0 if the same, and +1 if the internal is less.

The 20 here can be anything significantly more than 15, which is the approx. number of decimal digit accuracy for the hardware floats. Unfortunately the default software float accuracy is 10 digits and not some number higher than 15, otherwise we could get rid of evalf[20]() and save 11 bytes. evalhf converts to hardware float.

Python, 67 65 64 bytes

lambda n:D(n).compare(D(eval(n)))
from decimal import*;D=Decimal

"The obvious" as in using Decimal for the comparison. Only golfy idea is replacing float() by eval() to save 1 byte.

Attempt This Online!

Java, 80 79 59 57 bytes

s->s.compareTo(new java.math.BigDecimal(new Float(s))+"")

Outputs a negative integer if the internal floating point value is larger; 0 if they're the same; and a positive integer if the floating point is smaller.

Try it online.

Explanation:

s->                          // Method with String parameter and integer return
  s.compareTo(               //  Compare the input to (resulting in neg/0/pos):
   new java.math.BigDecimal( //   Create a BigDecimal, with value:
    new Float(s))            //    The (32-bit) floating point number of the input
   +"")                      //   Convert that BigDecimal to a String

Minor note: I've used Float (which is 32 bits) and therefore holds slightly different values than in the challenge description. If I would change it to Double (which is 64 bits) the values would be the same as the challenge description. This difference can for certain inputs also result in different outputs (e.g. the "0.09" is 0.0900000035762786865234375 as float, resulting in -23, but 0.0899999999999999966693309261245303787291049957275390625 as double, resulting in 1). The overall functionality would still be the same, though:
Try it online.

Python (v3.8+), 68 bytes

lambda d:(s>(t:=str(longdouble(float(d)))))-(s<t)
from numpy import*

Integers should be input with .0 (e.g. test case 2 is input as "2.0").
Outputs -1 if the internal floating point value is larger; 0 if they're the same; and 1 if the floating point is smaller.

Try it online.

Explanation:

lambda s:          # Function with a string as argument
  (s>              #  Check if the input-string is larger than:
    (t:=str(longdouble(float(d)))))
                   #  the internal floating point value of `s` as string
                   #  (which is also stored in `t`)
  -(s<t)           #  And subtract the s<t check from the s>t check to get -1/0/1
from numpy import* # Import for the `longdouble`

Vyxal 3, 1 byte

1

Vyxal It Online!

Outputs 1 if equivalent, 0 if bigger, -1 if smaller. This probably polyglots a lot of languages lol. Leave a comment if you have a polyglot language where the answer is always 1.

Notably, this always outputs 1. That's because all numbers are stored exactly by default. That's an intentional language design decision we went out of our way to accommodate by using a third party library under the hood. Technically, the number type is called VNum which extends spire.Complex[Real], so not a "decimal" type but a type that happens to also be able to store decimals exactly by consequence of also storing things like surds exactly.

There's a slight chance this could be considered invalid by the "don't use decimal type" restriction, but that's up to the challenge asker as to whether the default (and only) generic number type being exact is allowed.